Claims Based Authentication
Microsoft Dynamics CRM 2013 supports two authentication methods:
- Basic Claims Authentication
- Active Directory Authentication
Basic Claims Authentication
The concept of a “one size fits all” security for applications accessing from different locations with multiple devices does not work well and so Microsoft created the Windows Identify Foundation (WIF) to address this challenge.
WIF is a framework for implementing claims-based authentication used by Microsoft Dynamics CRM 2013 and other Microsoft applications such as SharePoint.
Claims based authentication uses an industry standard protocol so in theory we can use any Identify Provider to authenticate uses. In essence the authentication of users is handled by a third party.
Claims Based Authentication works together with WCF to provide secure user authentication and a communication channel with a Microsoft Dynamics CRM server. All Microsoft Dynamics CRM editions support claims-based authentication.
The following are some scenarios activated by moving to claims-based authentication:
- Support for any Security Assertion Markup Language (SAML) compliant provider
- Active Directory Federation Services to access Microsoft Dynamics CRM remotely using their existing identities with the need for a VPN.
Secure Token Service
Claims-based authentication requires the availability of a Secure Token Service (STS) running on a server. An STS server can be based on Active Directory Federation Services (ADFS) v2, or any platform that provides the official STS protocol.
Claims-based authentication is made up of a set of WS-* standards that describe the use of a Security Assertion Markup Language (SAML) token. The SAML token is either:
- Passive mode (when WS-Federation is used with both Microsoft Dynamics CRM 2013 and the Microsoft Dynamics CRM Online web application).
- Active mode (where WS-Trust is used with Windows Communication Foundation (WCF) clients).
Microsoft Dynamics CRM 2013 needs to trust the third party identify provide and accept users passed from the identity provider’s STS and has no need to perform further authentication.
To use Claims-based authentication you must first create a trust between Dynamics CRM and the STS.
Note: How to setup claims based authentication is covered in the MCRM course or refer to the following topics in the Microsoft Dynamics CRM 2013 Implementation Guide.
- Configure Microsoft Dynamics CRM for an Internet-facing deployment
- Claims-based authentication and Internet-Facing Deployment (IFD) requirements
- Configure relying parties for claims-based authentication
How Claims-based Authentication Works
To access a claims configured Microsoft Dynamics CRM 2013 server by using the Microsoft Dynamics CRM SDK, you must first install Windows Identity Foundation (WIF) on the development computer. The Windows Identity Foundation installs the Microsoft.IdentityModel assembly. This is referenced by the Microsoft Dynamics CRM SDK assemblies at run-time.
A request to authenticate a user is sent from Microsoft Dynamics CRM 2013 or Microsoft Dynamics CRM Online or a custom application to the STS server. The STS server determines whether the user should be authenticated, and if this is the case, issues a signed and encrypted SAML token that contains user authentication information.
How Active Directory Authentication Works
A request to authenticate a user is sent from Microsoft Dynamics CRM 2013 or a custom application to Active Directory. The WCF stack manages the authentication process for Microsoft Dynamics CRM SDK API calls from an application, whereas Internet Information Services (IIS) manages authentication for a web application.
Kerberos tickets created and passed between the computers and contain the user authentication information.