At A Glance

Web Single Sign-On

OpenASelect enables users to log in to a service provider once and gain access to other service providers without having to log in again. The OpenASelect server (OAS) remembers previous user authentications for a certain amount of time. When the user needs to be authenticated again, OAS will reuse the previous authentication result provided it is still valid and was sufficiently strong (see Multiple Authentication Methods). Single sign-on (SSO) works even when service providers reside in different domains.

Multiple Authentication Methods

OAS has multiple ways of authenticating users. Currently, it supports password-based authentication (e.g. against Radius or LDAP), PKI authentication (whereby the user has to provide a client certificate), and SMS / token-based authentication (whereby the user has to provide a password and a one time token sent to the user's phone by SMS). Authentication methods can also be chained.

OAS can be configured to use a specific authentication method when the situation calls for it. For example, users trying to access a service provider from the local network may only have to supply their password, whereas users from outside that network must supply a client certificate as well. Service providers with sensitive content, e.g. payment applications, can be configured to always require a strong authentication method.

Support for legacy and industry-standard protocols

OAS currently supports the A-Select 1.x protocol, OpenID and the DigiD protocol (acting as SP only). SAML2 support is currently under development. This allows service providers already supporting those protocols to integrate with OA without requiring any changes. It also allows OAS to be deployed in several existing federations, including the SURFnet Federation, the Kennisnet Federation, and the EDUpoort Federation.

Attribute provider

In addition to a user identifier, OAS can provide service providers with user attributes gathered from one or more sources. User attributes can be obtained from LDAP, SQL databases, web services, and other identity providers. Service providers can use these attributes to personalize content or to perform authorization.

Automatic user provisioning

OAS allows for user attributes used in the authentication process to be maintained in a separate database. Such attributes include retry counters, allowed authentication methods for that user, and any kind of authentication method-specific data (e.g. a phone number for SMS authentication). Organizations that do not want to maintain all or part of these attributes within their real user database (e.g. LDAP) can use the provisioning user database to avoid this problem. OAS provides transparent, real time synchronization of the real user database and the OAS-specific user database.

Authorization

There are several moments during a user's login attempt where an organization may want to perform authorization. OAS can perform authorization at several stages of the authentication process. The authorization process can not only allow or deny access, but can be configured to change the authentication process based on certain criteria. For example, an authorization rule may state that users coming from intranet must supply their username and password, users coming from extranet must use a stronger authentication method, and users coming from a certain IP range are simply denied access.

User interface customization

The OAS' templates have been designed so that the look and feel can be easily changed by modifying only the system-wide stylesheet. Moreover, most text and error messages come from resource bundles. You can change existing bundles or add new ones to, for example, add other languages. OAS supports localization by automatically selecting the correct resource bundle based on browser settings, server settings, or instructions from service providers.

The OAS user interface is based on Java Server Pages (JSP) technology. That enables organizations to make extensive modifications to the user interface without having to modify the OAS code itself.

Redundancy and scalability

OpenASelect is fully scalable and supports high availability setups. As such it is able to authenticate large numbers of users at once as well as guarantee a very high uptime. A simple failover setup only needs two OAS servers, one active and one standby. A typical scaled, high availability OpenASelect system consists of a load balancer and two or more OAS servers that are all connected to a high availability DBMS. Configuration, event logging, login sessions and other runtime information are all stored in the DBMS. OAS supports retrieving operational status information via SNMP, making it easier to integrate into existing network monitoring systems.