Claims to expect

KMD Identity will always return a claim named "identityprovider" and it has a value that matches the domain_hint of the Identity Provider (IdP) that was used to authenticate the user. The possible values are in our list of Identity Providers.

Which other claims are returned depends on the specific IdP that was chosen to authenticate the user. These IdPs can be divided into two categories. Those that return standard claims (the default for most integrations) and the exceptions to the rule.

Standard claims

By default KMD Identity ask upstream IdPs to provide:

• A Name ID that is both unique in their organization and persistent between sessions.
• 4 claims (with the one called "Otherphone" being optional).

If your application is using SAML to integrate with KMD Identity, the Name ID will be forwarded in the SAML subject.

If your application is using OpenID to integrate with KMD Identity, the Name ID value will be in the 'id token' claim called 'unique_name' and in the 'access token' claim called 'sub'. For clarification on the difference between the 'sub' claim of the id and access tokens, see this page.

Important: The Name ID that the upstream IdP provides is only guaranteed unique in their organization. Therefore, to uniquely identify a user that has been authenticated via KMD Identity, Service Providers should always:

1) Verify that the user has authenticated using a specific IdP (by reading the identityprovider claim) or
2) Identify the user using a combination of both Name ID and identityprovider.

The 4 claims we ask IdPs to provide are:

OpenID	SAML	Description
email	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Email of the authenticated user
given_name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname	Given name of the authenticated user
family_name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname	Surname of the authenticated user
Otherphone	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone	Phone number of the authenticated user

Exceptions to the rule

Some IdPs return a set of claims that differ from the standard set described above. Those IdPs are:

• Digitaliseringsstyrelsens NemLog-in
• STIL's Unilogin
• KOMBIT's Context Handler

They use subsets of the OIOSAML 3 Web SSO Profile specification. For details, please consult the documentation provided by those IdPs.

Note

KMD Identity also supports setting up product-specific integrations that can forward an arbitrary set of claims as agreed upon by the product owners and their customers. As these are product-specific they are beyond the scope of this document.