So in this blog I’ll discuss attribute mappings, what they are and how they work. This forms part of claims based authentication and which attributes are used when you setup a single sign on application.
I’ve referenced some documentation from both ADFS and Azure AD, although most organizations will push towards a modern identity platform the concepts and information found in the documentation for ADFS is useful, hopefully some information here will help.
Consider consulting your vendor or reading documentation, some vendors have custom attributes that will need to be created before the SSO can be configured.
So just to recap…….
- A claim is a piece of information sent in a SAML assertion that identifies some unique information about the user. This could be something like the email address or User Principal Name (UPN)
- More than one claim can be used depending on the application and security requirements
- The application can also be referred to as the Service Provider (SP) or a Relying Party Trust (RP)
- An application will use the claim(s) to authorize access to an application
For more information see Claims-Aware Applications
Here is the default set of claims and values in Azure AD
One of the prerequisites of setting up a SAML application is that both the Idp and SP need to agree on a set of attributes that can be mapped to ensure that the user can be authorized by the application. The mappings are preset and do not occur on execution of the application.
Using the ‘Edit’ button you can see which claim will be passed in the assertion when it is used to access an application, in this case the emailAddress attribute will be used.
In the example below is a screenshot from attribute and required claim. In this case the emailAddress is required to be passed in the SAML assertion.
For more information on attributes, claims and mappings