Claim based Authentication in Dyanmics CRM

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.

 

Next Recommended Reading Retrieve crm user based on Team ID