What is OpenASelect

OpenASelect is a platform for implementing a federated identity-based infrastructure. Such a platform consists of user information databases (e.g. LDAP servers), Identity Providers (IdPs), and Service Providers (SPs). IdPs provide user information from a certain security domain to SPs outside that domain. IdPs authenticate users to ensure that the provided user information is reliable. SPs consume the user information in order to control access to secure content. The separation of user information databases, IdPs, and SPs allows for cross-domain Single Sign-On (SSO), allows for organizations within a federation to provide secure content to one another's users, and removes the need for SPs to maintain their own user databases and implement their own authentication mechanisms.

The OpenASelect Server

The OpenASelect Server (OAS) is an open-source identity provider. Its role is to authenticate users and to provide user information to other SPs. The following figure shows an example organization with one OAS serving as an identity provider for a web portal and two other SPs:

In this setup OAS is used as an authentication provider for the organization's portal and two other, separate service providers. OAS allows users to log in to the portal, and then access the other two service providers without having to log in again (single sign-on).

Deploying multiple OpenASelect servers in a federation of organizations leads to a much more complex infrastructure. In such cases, OAS can delegate authentication to other IdPs (not necessarily OAS), or be asked to authenticate a user via a proxy IdP. The Federated authentication page provides several examples of federations.

Compatibility

OAS is backwards compatible with the A-Select 1.5 protocol. OAS also supports the OpenID protocol and the DigiD protocol when acting as service provider. SAML2 support is currently under development.

Authentication and Single Sign-On

The figure below shows the typical log in scenario. :

1. The user requests secure content from the service provider, but is not yet logged in.
2. The service provider redirects the user to the OAS Web SSO service.
3. The user requests the Web SSO service.
4. OAS authenticates the user, e.g. by verifying the user's username and password or client certificate, or by delegating authentication to another IdP (such as DigiD or another OAS). If the user was authenticated before and that authentication result is still valid, then OAS uses that previous authentication result instead. In that case no user interaction takes place at the OAS.
5. OAS redirects the user to the service provider along with proof of authentication. Depending on the protocol, that proof can be a fully self-contained statement (e.g. SAML2 Browser/POST profile) or a token that can be used to obtain the actual proof (A-Select 1.x protocol, SAML2 Browser/Artifact profile).
6. The user requests the service provider's proof consumer service. If the provided proof is a token, the SP requests the actual authentication statement by sending the token directly to the OAS.
7. At this point the SP has proof of authentication, has received a user identifier, and has optionally received a set of user attributes. The SP may choose to perform authorization based on the received attributes. Once the SP has allowed access, it creates a session for the user and redirects the user to the secure content.
8. The user requests secure content from the service provider, and is now logged in.
9. The SP responds with the requested content.

Attributes

OAS is able to provide user attributes gathered from one or more sources, including LDAP and SQL databases. Attribute release policies can be configured to define the set of attributes that each known service provider may receive.