Technical Overview of the OpenASelect Server

Authentication process

The OpenASelect core functionality can be combined with a large range of authentication, authorization methods, and profiles. Although the user experience can vary substantially between different configuration settings, the general work flow is mostly equal.

In general the following steps take place in the authentication process:

Step 1. Trust establishment

In order for the SP to trust claims made by an IdP, it must trust both the claim itself and the origin of the claim. For many types of requestors, trust is established by exchanging digital certificates. Exchanging certificates usually takes place via out-of-band communication, but can also take place via an API call defined in the protocol (e.g. OpenID). The certificates are used to verify signatures within message exchanges between an SP and an IdP. This ensures message integrity and authenticity, i.e. it ensures that a claim from an IdP has not been tampered with and that it was really supplied by that IdP.

Step 2. Authentication request

The authentication starts with the SP sending a request for authentication to the IdP. The request may include parameters that tell the IdP how to authenticate the user. For example, the request may indicate that a previously established SSO session should be ignored, or that a strong authentication method is required.

The authentication request is sent in a message that has a certain method of transport: the binding. The protocol that is used for the communication between IdP and SP defines the binding. The requestor profile component of OpenASelect receives the message, extracts the information in the message and stores details for later use (if necessary). The authentication session context is created, the user is redirected to the WebSSO and thereby the first part of the requestor profile process is finished.

WebSSO tasks

The WebSSO is responsible for authorization, Authentication, and Single sign-on session initialization. Details of these tasks are out of scope of this article, but can be found in the specific articles.

Step 3. Authentication response

After authentication at the WebSSO, the user is redirected back to the profile. The profile restores the session context and uses the properties established (e.g. authentication result, authentication context type) during the authentication phase to form an authentication response. The response is bound according to the protocol used for the authentication session and is sent to the SP. Transport of the authentication response to the SP occurs via the user agent.

Step 4. Authentication verification

Because the authentication response is transported via the user agent, the response must be verified before privileges can be given to the user. A response can be verified by one of two methods: 1. The response includes a proof that can only be generated by the IdP and therefore guarantees that the message is supplied by the IdP and is not tampered with, and 2. The protocol includes an API call that allows the SP to verifiy the response directly with the IdP.

Protocol steps

The four phases depicted above have the following corresponding protocol messages:

	A-Select 1.5 protocol	OpenID authentication 2.0	SAML v2.0 Web browser SSO profile
IdP-SP Trust establishment	Out-of-band key exchange	openid.mode=associate*	Out-of-band key exchange
Authentication request	request=authenticate	openid.mode=checkid_setup	<AuthnRequest>
Authentication response	reply to request=login1	reply to checkid_setup (openid.mode=id_res)	signed <Response>
Authentication verification	request=verify_credentials	openid.mode=check_authentication*	Message signature verification

* = OpenID authentication 2.0 specifies that at least one of openid.mode=associate or openid.mode=check_authentication should be used.

OpenASelect internal structure

The above section establishes the external relations of the OpenASelect server in the case of an authentication procedure. For a good understanding of the workings of OA, the internal components and their relations are discussed.

In the above image, the relations depicted in the authentication process section of this article are simplified. The internal structure of OpenASelect consists of three main parts:

OA Engine

The OA Engine is, as its name may suggest, the provider of core functionality. The engine is used by the profiles and WebSSO components for basic operations such as storage (of session information, configuration, cypher keys, etc.), encryption and decryption, and session management. The engine conceptually consists of the following components:

• Storage - Forms an opaque storage layer. It allows information requiring persistent storage to be stored, regardless of what actual storage backend is used. The storage is used for authentication session and TGT (SSO Session) information and user provisioning. Also, the configuration to be used by the business logic layer is retrieved via the storage layer;
• Core - Provides essential services needed by multiple other components. These services include cryptographic functions, User provisioning, Session and TGT management, and Event logging;
• Business Logic - The business logic layer represents the configured behavior of the OA authentication process. Configuration is loaded via the storage layer and is used to drive the SSO Controller and Core functionality. Items managed via the Business logic layer are the application pools, authentication profiles, authorization profiles, and attribute release policies;
• SSO Controller - The SSO controller forms the backend of the WebSSO component and provides the necessary information in order for the WebSSO to perform the different steps in the principal's authentication.

Requestor profile

A Requestor profile component consists of a main handler class, receiving all requests, and a series of helper classes. The main class is responsible for handling the requests sent by the SP as well as the principal. The goal of the profile component is mainly to interpret requests sent with a specific protocol binding and respond with assertions wrapped in a binding belonging to the same protocol.

Besides the implementation of the authentication protocol, the requestor profile is responsible for Attribute gathering and release.

For more information on requestor profiles in general and the different profiles that come with the OpenASelect package, visit the article on profiles.

WebSSO

The Web Single Sign-on (WebSSO) component only communicates with the principal in order to establish the proof of the principal's identity. The steps the WebSSO component performs are 1: (pre-)authorization, where decisions can be made based on properties of the initial authentication request that influence the authentication process, 2: authentication, to establish the principal's identity and proof that identity and 3: the initialization or extension of the Single sign-on session, which is set in the user agent via a cookie.