Manage Authentication Context Schema

In the instruction below, we are adding a new attribute, representing the user’s nickname, to the predefined authentication context schema. As a result, we will be able to map data incoming from IDPs to this attribute. This way, you can create any authentication context schema matching your needs.

1. Within your workspace, navigate to Auth Settings » AuthN Context.

   Result

   List of predefined authentication context attributes is displayed.

2. Select CREATE ATTRIBUTE from the Authentication Context view.

3. In the Add attribute dialog box, fill in the Name, Data type, and Description fields.

4. Select Create to save your new attribute.

   Result

   Your new attribute is visible in the Authentication Context Schema view, meaning that you can now proceed to mapping IDP-specific attributes to it.

Map IDP Attributes to Authentication Context Schema

By mapping your identity attributes, you unify attributes from all IDPs that your users authenticate with into a single authentication context. It allows you to use a set of unified attributes throughout the workspace for multiple purposes. In the video below, we’re mapping the email attribute from Sandbox IDP to the My new attribute attribute defined in the authentication schema. This means that the value of My new attribute is taken from the email parameter of the incoming Sandbox authentication requests. Finally, the new attribute is exposed as a claim in the demo application using Data Lineage.

1. Select Identity Data > Identities from the left sidebar.

2. Select an identity connection from the list of available IDPs.

3. Select Mappings from the top menu.

4. Configure each source-target attributes pair so that a source attribute matches a target one.

   1. Select a source IDP attribute name from the drop-down list.

      Note

      • If the source attribute is not defined out of the box (for example when the IDP provides a custom attribute, such as crm_id), you need to add this attribute to the IDP before you can map it.
      • To add an attribute for your identity, go to Identity Data > Identities (left sidebar) > Identity (from the IDP list) > Attributes tab > Add attribute.

   2. Select a target authentication context attribute from the drop-down list.

   3. Select Save mappings. Your mappings are added to the list.

Cache Authentication Context

Since Cloudentity is stateless by default and caches no user’s data, it needs to call IDP every time the user wants to re-authenticate during one session to, for example, request another scope. The stateful authorization feature allows to store the user’s authentication data, including the login status, locally in Cloudentity. With this feature enabled, Cloudentity can cache the user’s data and issue multiple tokens during one user’s session without re-authenticating the user.

With the stateful authorization, the efficiency of issuing tokens in Cloudentity is significantly improved by minimizing latency and performance degradation related to repetitious calls to IDPs.

Dynamic Auth Flows

Recent trends in standards for the token-based access control show the inclination to the fine-grained token issuance and starts favoring short-lived tokens issued for a specific purpose.

The use of the stateful authorization is particularly vital in the context of dynamic authN/authZ flows. The dynamic flows, as opposed to traditional ones, can support multiple access tokens per client application’s session. In the traditional flows, the client requests a token when the user launches the app and continues with this token and its initial list of scopes. In the dynamic flows, during one session, the client application can requests multiple tokens: each for accessing a different application component. This so called intent-based authentication often supports online payment services and the use of dynamic scopes.

Enable Stateful AuthZ

In the Cloudentity portal, you can enable the stateful authorization per IDP and configure for how long the user’s data stay cached in Cloudentity.

1. Select Identity Data > Identity Providers from the sidebar.

2. In the Identities view, select an identity provider (IDP) that you want to configure.

3. Select the Authentication Context Caching toggle.

4. Set the time for keeping the user’s data cached in Cloudentity.

   Note

   Set a non-zero value for the time. Otherwise, the feature gets disabled automatically.

5. Select Save.

Enrich Authentication Context

Extensions that happen after users are authenticated with their identity source are used to enhance the authentication context of the authenticated entity. Such enriched authentication context can be later on used to populate claims in tokens minted by the Cloudentity platform.

The Post Authentication script allows custom JavaScript code execution upon user’s authentication, enabling the modification of certain authentication context attributes, enhancement of the user context, or triggering custom API calls.

The Post Authentication custom application option described in this document allows connecting a Third-party Application to Cloudentity. This application can interrupt the authorization flow after the user logs in using an IDP, redirecting the user to a custom, business-specific application hosted by the customer. This application requires users to complete additional processes or interactions as needed during the authentication process before they can proceed to granting their consent to the client. When the user completes this third-party flow, they are redirected back to the original authorization flow.

Extensions that are placed post identity source authentication can be used:

• To pull data (such as, for example, user permissions) from an external system

• To overwrite static attributes in the authentication context

• To enhance authentication context with risk information from external services

• Enhance authentication context with business information for the user from external services (like subscription or licensing)

• Enhance authentication context with static attributes, for example, to dynamically set the AMR and ACR Claims for Open Banking

• Transform identity claims from identity provider using various functions

• Asking the user to provide missing profile attributes

• Asking the user to provide additional context for the authentication process, like State, District or Organization

• Triggering a separate custom business process that requires user interaction