This blog describes how Claim based authentication works in Dynamics CRM
Claims-based authentication
The claims-based security model extends traditional authentication models to include other directory sources that contain information about users. This identity federation lets users from various sources, such as Active Directory Domain Services (AD DS), customers via the Internet, or business partners, authenticate with native single sign-on.
The claims-based model has three components: the relying party, which needs the claim to decide what it is going to do; the identity provider, which provides the claim; and the user, who decides what if any information they want to provide. Microsoft provides a claims-based access solution called Active Directory Federation Services (AD FS). AD FS enables Active Directory Domain Services (AD DS) to be an identity provider in the claims-based access platform.
![]()
Contents of the SAML Token (Security Assertion Markup Language)
The XML-based SAML 2.0 token contains an identity that defines one or more claims about a user. This token is passed between an identity provider (STS) server and Microsoft Dynamics CRM for claims-based authentication. The claims in the identity have been defined as follows.
| Claim | Use |
| Universal Principal Name (UPN) | Contains the user’s ID in domain\alias format on the target Microsoft Dynamics CRM server. |
| Name | If the authenticated user is also a Deployment Administrator in Microsoft Dynamics CRM, this claim contains the deployment administrator’s ID in domain\alias format on the target Microsoft Dynamics CRM server. Windows Identity Foundation maps the Name claim to the Identity.name property. |
| Any other claims | Not used by Microsoft Dynamics CRM. |