Application level architecture
Table of Contents
General
The Asimba application performs the task of answering requests for an identity. To respond to such a request, it performs authentication, authorization and user provisioning tasks. The application is architected in a generic way, so the task of authentication, authorization and user provisioning are abstracted into a generic procedure.
Web- and non-web targets
As Asimba SSO is primarily used in a web-based deployments, most of the implementation is written for use on the web. The architecture is designed to support both web-based as non web-based deployments though.
Pluggable architecture
The Asimba SSO Baseline Server distribution provides a wealth of features to support the most commonly used scenarios in which an Identity Provider is being used. Due to its design, it is easily possible to extend or modify much of the functionality, without having to touch the core of the application. This introduces a level of flexibility that makes Asimba SSO a candidate for being integrated in many environments.
This document provides an overview of the Asimba application architecture in relation to the features that are part of the Asimba Baseline Distribution.
Application Architecture
Overview and Bootstrap
Asimba is created as a J2EE application, and implements a typical middleware component by offering:
- a frontend, that supports different identity provider protocols (i.e. SAML, A-Select)
- a backend, that supports different authentication methods, including remote SAML or A-Select to support protocol briding
The heart of Asimba SSO, the so called Engine, is started by a launcher process (OAContextListener), that establishes the context in which it is being run. The launcher is typically instantiated by an ApplicationServer. Once the Engine has started, the other (servlet) components of Asimba SSO are launched, as they are dependent on Engine being initialized with its provided context.
Servlets
The servlets that are part of the Asimba SSO Baseline Server, are:
1. OAServlet
2. WebSSOServlet
3. ManagerServlet
4. AxisServlet
A short description of each of these servlets follows.
OAServlet
The OAServlet is the servlet that receives a request for an identity, and as such it is the front door for users to ask for Asimba’s services. A request is being handled either by an IDP Profile, or by a generic Helper. An IDP profile will execute an Identity Provider protocol, like SAML2, OAuth or A-Select. All of which are part of the Asimba SSO Baseline Server distribution.
The behavior of OAServlet is configured through the ‘profiles’ and ‘helpers’ sections of the main configuration branch of the Asimba configuration file.
| Technical notes: | |
|---|---|
| Module | asimba-wa |
| Implemented in | com.alfaariss.oa.OAServlet |
WebSSOServlet
The primary task of the WebSSOServlet, is to coordinate a security context with a user in a web world. To accomplish this, it contains access to a WebProfile for authenticating a user and setting up a security context with the user, a UserProfile to provide the user with information about the actual security context, and a LogoutProfile for ending the security context.
It is possible to extend the WebSSOServlet with custom features, by implementing another profile. In the Asimba SSO Baseline Server distribution, there is no additional functionality provided with WebSSOServlet though.
The WebProfile service implements a generic way to establish the security context of the user. The Security Context is established through a process that involves (pre)authorization, authentication and provisioning. To do this, WebProfile can rely on the web-based context in which it is operating. Another section will provide more info on the process of establishing the security context with the User.
The behavior of WebSSOServlet is configured through the ‘websso’ section of the main configuration branch of the Asimba configuration file. This section specifies how authentication and authorization methods behave in a web-based environment.
| Technical notes: | |
|---|---|
| Module | asimba-sso-web |
| Implemented in | com.alfaariss.oa.sso.web.WebSSOServlet |
ManagerServlet
The AsimbaSSO Service process can be managed through the ManagerServlet. There is some basic functionality available to (re)start and stop the AsimbaSSO Service, and provide a custom context to restart the service with.
The ManagerServlet should only be made available to authorized users, because it controls the availability of the Asimba SSO service.
| Technical notes: | |
|---|---|
| Module | asimba-wa |
| Implemented in | com.alfaariss.oa.ManagerServlet |
AxisServlet
Axis is a SOAP handler, that provides a Web Services interface to Asimba SSO. It is used to support SOAP-based authentication requests. AxisServlet is used for example by A-Select IDP profile to support the SOAP binding.
Core components
The Asimba Engine manages the core components that provide the foundation upon which the SSO Identity Provider functionality is built. These core components are shared within a deployment of Asimba. A figure provides an overview of all the components.
Engine is started with a runtime context by EngineLauncher. The context can point to a specific configuration that must be used for the running Asimba SSO instance, and is established by EngineLauncher.
This section gives a brief explanation of all the components. A more detailed description of the components is provided in another section of the Asimba documentation.
All these components are part of the Asimba core set of functionality.
| Component | Description |
|---|---|
| pre-authorization | the profiles that are available to perform pre-authorization, before trying to establish a security context |
| authentication | the profiles that are available to authenticate a user |
| post-authorization | the profiles that are available to perform authorization based on the security context of an authenticated user |
| attribute-gatherer | the profile that will collect the attributes of an authenticated user |
| attribute-release | the profile that decides which attributes can be released in a response to an identity request |
| storage-factory | an optional configuration of system- and model-storage facilities for storing application context information |
| crypto | generic cryptographic facility (keys, trusted certificates, etc.) for the service deployment |
| tgt-factory | the Ticket Granting Ticket (SSO-ticket) storage facility |
| session-factory | the user-session storage facility |
| requestorpool-factory | the storage backend where requestors are registered |
| user-factory | the storage backend where users can be retrieved from |
| idp-storage | the storage backend where remote Identity Providers are registered (used when acting as proxy) |
| Technical notes: | |
|---|---|
| Module | asimba-engine-core |
| Implemented in | com.alfaariss.oa.engine.core.Engine |
