
Figure 1. Authentication and authorization process

Process Steps

Discovery (Missing from the diagram, first step before authentication)

Discovery means determining the correct authentication method for the user presented. This can be based on information we know about the user before authentication, such as IP address, or a user selection or can be determined by the requesting application. The application that the user is trying to access also determines what type of authentication is required.

Authentication

Here we authenticate the user using the chosen technique. Some authentication methods are built-in to the system and others are made through calls to external services. The authentication method used sets the level of assurance for the user identities – that is how much we can be sure about who the user is. Authentication methods can be group into logical sets and presented to the user in a chosen order and grouped for easy selection. Some authentication methods stop the user and ask for information, such as username and password, whilst others occur silently, without interrupting the user, such as Windows SSO.

Some authentication methods provide two-factor authentication by being the second factor (aka step-up) method and require a Password (SPI Password) method as the first factor. These step-up methods are:

SMS OTP (SPI Mobile Phone)
OTP Printout authentication method - SSO (SPI Ubikey OTP Printout)
Mobile ID (SPI Mobile PKI)
Time-based OTP (SPI TOTP)

Applications may be configured for two-factor authentication in two ways.

1. Application requires step-up authentication by allowing only step-up methods and not a password method.
a) Users with the step-up methods enabled are allowed to access the application.
b) Users without the step-up methods enabled are not allowed to access the application.
2. Application allows password authentication and step-up authentication.
a) Users with the step-up methods enabled are required to authenticate with the step-up method.
b) Users without the step-up methods enabled are allowed to access the application with only password method.

Usecase 1 can be configured by selecting only step-up methods as Allowed Methods for the application.

Usecase 2 can be configured by selecting both step-up methods and the password method as Allowed Methods for the application.

Method Attribute Mapping

Using the attributes returned from the authentication provider, we can rename and modify the attributes into a format that application can use. This helps to standardize the attributes returned from various services to make rule processing easier. Backend services can be used to assist in the method attribute mapping, if required. Method Attribute Mapping is optional and this stage can be skipped if not required.

Directory User Mapping

In many cases the user has an existing account. Directory User Mapping is used to search for the user from the chosen user directory. After a match is found, all of the user record attributes are also available to the Identity Broker Engine. Directory User Mapping is optional and this stage can be skipped if not required.

Identity Creation

Now that these steps have been completed, a session is created. The steps before this step are not required to be repeated if the user attempts to access a subsequent application. In that case, the process starts from here. In a browser situation, a reference to the session is done by cookie or session tokens.

For every application the user accesses, the following steps are performed:

Group Mapping

Based on all of the information available, the user belongs to various access control groups. This stage evaluates all of the group memberships dynamically. These are checked each time, as the user may have been removed or added to an access control group since the previous application access. Group Mapping is very flexible and a few examples of usage can be found below.

Access Control

For every application, we check that this user belongs to a group on the "Allowed To" access control group list. If not, access to the application is denied. Furthermore, we evaluate that the user has all required mandatory attributes that the application demands.

Authorization Policy (Attribute release by authorization policy)

The Authorization policy defines what attributes are sent to a given application and in what format. The user's group membership helps to determine the format. With OpenID Connect, OAuth 2.0 and Mobile Connect applications attribute release can also be scope based, which means that the attribute is released only if the scope specified for the authorization policy is present in the requested scopes. The attribute release can also be dynamic, using an extensible Authorizer component. To protect user's privacy, only the specified attributes are sent.

Examples

Example 1 - A user is logging in to salesforce using a smart card.

Discovery
We use the IP address of the user to automatically determine that he or she is a local network user.

Authentication
we check the user identity using the smart card.

Method Attribute Mapping
We select one or more user attributes from the certificate on the card and discard others.

Directory User Mapping
We use the selected attribute, such as the serial number of the card, to find the user in the company Active Directory.

Identity Creation
Now the identity has been created

Session Creation
The Session is created

Group Mapping
We can look at group information from external directories, such as the Active Directory memberships or create dynamic group membership based on which authentication method was used.

Access Control
For the salesforce application, we check that the user belongs to a group that is allowed to access the SalesForce application. The user is on the sales team according to the Active Directory, and so will be granted access to SalesForce.

Attribute Release via the Authorization Policy
SalesForce requires that the user's email address is sent alongside basic contact information. We retrieve these attributes from the session and present them to Salesforce in the correct format.

Example 2 - An external user is logging in to a custom B2B business application using SMS or printed one-time password list.

Discovery
The user enters a user name and password and is presented with the two possible options, SMS or printed one-time password list and chooses themselves. The user chooses SMS.

Authentication
We send a one-time password by SMS to the user and the user enters the one time password to complete the authentication.

Method Attribute Mapping
This stage can be skipped if not required.

Directory User Mapping
This user has been identified in the CustomerID directory during authentication and now all of the attributes are available for further processing.

Identity Creation
Now the identity has been created

Session Creation
The session has been created

Group Mapping
We can look at group information from CustomerID to assign various roles to the user.

Access Control
For the custom B2B application, we check that the user has the required application role.

Attribute Release via the Authorization Policy
The custom B2B application needs the user's email, first name, last name, customer number and roles that are related to this application. We present them to Salesforce in the correct format.

Browser not supported