Identity Federation - Identity Mapping vs. Claim Mapping

Identity and claim mapping become important, when the target realm (A) of a web application is not equal to the home realm (B) of the user. In this case a SAML token from the user (issuer B) cannot directly be validated at the web application (trusting issuer A only). The relaying party IDP of the web application (in realm A) is able to exchange the SAML token from the (trusted) home realm (B) into a SAML token applicable for the target realm (A). This exchange can be based either on identity mapping or on claim mapping. In this post I'm going to explain what's the difference between these two mapping styles and when to use which alternative.

<!-- TODO: add picture here -->

When the relaying party IDP (A) requests a SAML token on behalf of the user (B) at its STS (A) for a specific application (A), then the relaying party IDP send the SAML token previously received from the users home IDP (B) to its STS (A). The STS validates the SAML token and detects that it was issued from another (trusted) security realm (B). Depending on the STS configuration the new SAML token can be created based on an identity or claim mapping.

Identity Mapping

Identity mapping is usually required if a user is registered in both (target and home realm) security domains with an individual user each. These users can be managed in both security domains independently. They do not need to share the same username, password or other kind of user attributes like assigned roles.

A good example of this use case can be illustrated by Google and YouTube. Before Google acquired YouTube most users had a normal Google account as well as an independent YouTube account. After the acquisition, Google implemented an identity mapping so that a user with an active Google session (due to previous login) could login to YouTube and Google would ask the user if he/she wants to link both accounts. If the user agreed, he/she was now able to login to Google only, but at the same time he/she could use YouTube without re-authentication and with all settings, playlists, etc. which have been related to their former YouTube account.

For identity mapping the following constrains apply:

• Independent user account (including attributes) per security domain
• Each account is under local administration
• A mapping needs to be defined between account names
• No attributes are mapped from one identity to the other

Claim Mapping

In case of claim mapping a user is completely managed and under the control of only one domain. Users do not need to be known and managed in other security domains. This reduces the need for identity synchronization and confidential information like user credentials do not need to be propagated to other security domains.

When the STS receives a SAML token from another (trusted) security realm it does not need to look up a matching identity in his own security domain, but instead creates a new SAML token valid for the target security realm but with the same username as in the provided SAML token from the other domain. If user specific attributes (claims) are of interest for the target domain, the STS can simply copy these attributes into the newly created SAML token or execute a more complex mapping where original values do not need to match new claims neither in number, name nor value. If such a mapping is required, the STS needs to be configured accordingly. See my other post about how this can be done.

A simple claim mapping could be implemented in a way that role claims from a SAML token are also included (one to one) in the newly created SAML token. Alternatively a mapping could be defined to map role claims from one domain into different role claims for the target realm.

For claim mapping the following constrains apply:

• User account is only available and managed within its home realm
• No user account information is stored in the target realm
• If claims are needed in target realm, they need to be mapped accordingly