OpenID Connect conformant mapping of ADFS attributes to (id_token) claims

Help
, , , ,
1

this question is about the mapping of ADFS user information attributes / ACTIVE DIRECTORY attributes <-> OIDC (OpenID Connect) standard claims. (also referring to: Connect Your App to ADFS)

How do the mapping rules have to look like if you want to end up with having all OpenID Connect standard claims](Final: OpenID Connect Core 1.0 incorporating errata set 1) contained within the id_token?

In the example from Auth0’s ADFS docs “only” these few mappings get mentioned:

types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"), query = ";mail,displayName,userPrincipalName,givenName,sn;{0}", param = c.Value);

We tried that and in the resulting id_token …

  "name": "...",
  "given_name": "...",
  "family_name": "...",
  "nickname": "...",
  "picture": "...",

… amongst some other claims (some standard JWT token claims, some seemingly Auth0 specific) the above subset of the OpenID Connect standard claims was present.
I wondered why these were present in the id_token - and also in the Auth0 user’s raw JSON representation as I found out - although none of these are in the above mapping.

How does Auth0 (internally most probably?) map claim types (I guess it’s all of those, is it?) to OpenID Connect standard claims?
How does a complete mapping have to look like in order to get all OpenID Connect standard claims?

1 Like
2

There’s some special handling for some of the default claim types that ADFS can return. For example:

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress maps to email;
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname maps to given_name;
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname maps to family_name;
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name maps to name;

In addition, the user_id can be mapped from more than one claim and there’s also some support for groups, but groups are not OIDC compliant. For any other the behavior you should get is the one documented here, more specifically:

Auth0 will use the name part of the claim type (i.e. locality in http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality) as the attribute name for the user profile.

If you want to have a OIDC attribute automatically included in the user profile based on the claims coming from ADFS then you should consider the above rule. For example, if you wanted to fill the birthdate OIDC attribute with a value coming from ADFS you could try to have a claim similar to the following returned:

http://schemas.example.com/claims/birthdate

As an alternate possibility, there is support for custom mapping logic when configuring a SAML connection; IIRC, ADFS also supports SAML so you could consider integrating ADFS through a SAML connection instead of directly through an ADFS connection.

3

As currently ADFS doesn’t support custom mapping, switching to SAML for your ADFS connection could be a solution as @jmangelo mentioned. Related steps for how to setup ADFS with SAML is summarised below;

1-) Export the signing certificate from ADFS. You can export the certificate in the CER format that Auth0 will understand by selecting the signing certificate, selecting “View certificate” from the context menu, then selecting the “Details” tab and clicking on the “Copy to file” button. The Certificate Export Wizard will show up, and on the second page you need to select the Base-64 encoded X.509 (.CER) format.

2-) Follow these instructions to create a regular SAML connection: Configure Auth0 as SAML Service Provider Upload the certificate you exported in the previous step. The sign in and sign out URLs are usually in the form of https://your.adfs.server/adfs/ls

3-) Create a new relying party trust in ADFS. Make sure that the Relying Party Identifier is in the urn:auth0:account:connection format (Auth0 will show this in the setup instructions for the connection), and that the SAML Assertion Consumer Endpoint (callback URL) includes the connection name (i.e. https://{yourAuth0accountdomain}/login/callback}/login/callback?connection={your new SAML connection})

4-) The claims mapping in the ADFS server would be configured similarly to what is described at Connect Your App to ADFS

5-) In the Auth0 Dashboard, enable this connection for at least one client, and try.

Note that, you could configure custom mappings for a SAML SP connection from the enterprise connection section of the management dashboard.

alt text

4

@jmangelo you said “the user_id can be mapped from more than one claim”

Can you please

  1. confirm that the default claim user_id gets mapped from is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier ? (of course there’s still the connection part within the user_id attribute)
  2. give some examples or better links to documentation how the mapping from more than one claim gets done?