Processing claims (user attributes) from the AS in IAM

IAM can process user claims - pieces of information about a user - from different resources and use them in authentication flows and identity propagation.

In this context, the term resource refers to sources of claims and should not be confused with the Resource Server defined in OIDC. In the IAM configuration, use resource mappings to map remote resources to the local IAM user.

• Possible sources of claims are:
• ID token
• Remote service endpoints (e.g., userinfo endpoint)

• Possible types of claims are:
• User identities (username, sub, issuer, aud, etc.)
• Roles
• Context data
• Information related to authentication and authorization (ACR values, scopes, etc.)
• Technical information (validity, etc)

To determine the user identity of the foreign authorization server, it is required to configure at least one resource mapping that defines the username.

• In addition to the username, any other resources available may be mapped at login:
• User role resources will map their values into the authentee roles of the user logging in.
• User context data resources will map their values into the authentee context data.

In order to avoid ambiguity and to ensure a valid username, exactly one Remote Username Resource must be configured.

In OpenID Connect, it is possible to use an ID Token resource (claim) instead of requesting a remote resource to be mapped.

• The configuration of resources is organized in the following way:
• One or more resource requests may be sent to a resource endpoint at login.
• For each of these resource requests, there is a list of Contained Resources. This allows taking advantage of resource requests that return more than one piece of information at a time.
• Contained resources may be one of three types
1. OAuth 2.0 Remote Username Resource– uniquely identifies the username.
2. OAuth 2.0 Remote User Role Resource– these values are available as authentee roles after login.
3. OAuth 2.0 Remote Context Data Resource– any other information about the user.
• To maintain a high level of compatibility, the access token format can be configured differently for each request.

This diagram shows the involved plugins and their relationships:

If the user-defined through the resource mappings should be authenticated as is (meaning that Account Linking is disabled), users logging in via OAuth 2.0 do not exist in a local database but reside completely on the authorization server, all components depending on users being in a local database have to be disabled.

The collection of claims is the only particular part of using IAM as a client. Once the claims are available, they can be used in regular identity propagation.

Identity propagation is configured on the target application and it may combine a subset of the collected claims to be forwarded to that target application to identify the user.

• Internal links:
• Identity propagation