ADFS Integration with Dynamics 365 - Part 1

One of the complex requirements we get during the delivery of Dynamics 365 projects is to allow users from external domain to access CRM using their existing domain accounts without creating new accounts in the CRM domain. To achieve such requirements, we have two options:

1. Establish domain trust between the CRM domain and the external domain. This option is an old style approach and unsecured.

2. Utilize ADFS servers and WAP proxy servers to establish the user authentication trust in a secure and modern way which is what this series will be talking about.

Due to the complexity of such an Identity Federation option, we will be talking about it in a series of articles. The first article will be mainly focus on understanding the terminologies and building the foundation of how ADFS works as an Identity Federation Provider to authenticate internal & external users. This requires good infrastructure knowledge in addition to the Dynamics 365 architecture knowledge.

What is ADFS?

Active Directory Federation Service is currently a Windows Server component that Microsoft proposes for Single Sign On scenarios. ADFS 3.0 is part of Windows Server 2012 and the latest version is ADFS 4.0 which is part of Windows Server 2016.

What are SAML tokens?

Security Assertions Markup Language (SAML) tokens are open standards consisting of XML representations of claims, these claims contains a set of key and value pairs issued by the trusted identity provider and presented to the relaying party to identify the authenticated users. The token are signed by the security token service and optionally can also be encrypted. SAML is used to achieve SSO between different application and even domains.

Its important to note that SAML is a standard type of token. It has more than one version. The first version was SAML 1.0, then 1.1  - which wasn't very mature. Now the latest version is SAML 2.0 which is widely adopted.

What are the main ADFS components?

1. Service:

   1. Endpoints: the most important end points are the following:

      1. ADFS Login page: https://server/adfs/ls/IdpInitiatedSignOn.aspx

      2. ADFS Federation metadata URL: https://server/FederationMetadata/2007-06/FederationMetadata.xml

   2. Certificates: whenever a certificate gets expired, it must be renewed and the other identity providers using the federation metadata URL must update their reference.

      1. Service Communication Certificate: must be publicly signed certificate.

      2. Token Signing Certificate: usually self-signed (can be multiple but only one is primary).

      3. Token Decrypting Certificate: usually self-signed (can be multiple but only one is primary).

2. Authentication Policies: make sure to enable forms authentication.

3. Trust Relationships:

   1. Claims Provider Trusts: this is having the list of trusted identity providers.

   2. Relying Party Trusts: this is having the list of trusted applications or other identity providers.

How Does the ADFS Authentication Process Work?

ADFS authentication process is illustrated in the above diagram in 11 steps that can be found below in more details:

1. The Client access Dynamics 365 Web app public URL.

2. Dynamics 365 redirects the client to the primary ADFS home page (ADFS hosted under the same Dynamics 365 domain).

3. The user accesses the primary ADFS home page and selects one of the identity provider options as shown below. The blue icon represents the primary ADFS. Oher black icons are for other trusted identity providers.

1. The main ADFS redirects the client to the selected identity provider home page for authentication.

2. The client lands in the Login page for the selected identity provider and enters username and password to be authenticated by the identity provider.

3. The ADFS authenticates the client with the domain controller. If the client is authenticated successfully, a SAML token is issued for the client to be presented to the primary ADFS.

4. Client is redirected back to the primary ADFS.

5. Client posts the SAML token generated from his identity provider to the primary ADFS.

6. Primary ADFS processes the client SAML token by applying the claim rules configured for this claims identity provider, issues a new SAML token, and redirects the client to Dynamics 365 Web App.

7. Client presents the SAML token generated from the primary ADFS to Dynamics 365 Web App.

8. Client is granted appropriate access to Dynamics 365 Web App.

In next article we will be talking more about the required configuration steps to achieve such identity federation requirement.