What Authentication Context Is

Cloudentity enables organizations to standardize user data from various IDPs. Each IDP conveys authentication data differently, depending on its type and configuration. This data is mapped to a standardized schema in Cloudentity, the authentication context, which simplifies policy validation and claim definitions.

Cloudentity provides a predefined authentication context schema and standard attribute sets for each IDP, saving you the effort of creating one from scratch.

In the above screenshot of the Cloudentity Data Lineage View, you can see how the email user attribute coming from different IDPs (Identity Pools, Google, GitHub, and Sandbox IDP) is mapped to the email authentication context attribute. If any of those IDPs would use a different name for the email attribute – for example, address – it would be harder to have universal authorization policies and claim definition. Because the email attribute coming from different IDPs is mapped to a common authentication context attribute, you can, then, map this authentication context parameter to token claims included in the security tokens issued for client applications registered in the workspace.

In the Data Governance flow visualization, you can also observe how having a common authentication context for all IDPs makes it much simpler to assign authorization policies that prevent unauthorized application from getting access to resources. Because of the unified context, you can have only one policy checking the authentication context attribute instead of multiple policies checking for different attributes coming from IDPs.

Mapping Attributes

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.

Enriching 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

What’s Next

1. Add authentication context attributes.

2. Map Identity Provider’s attributes to the unified authentication context.

   If you added any custom IDP user attributes, you need to make sure they are correctly mapped to the corresponding authentication context attribute.