CRM Authentication

In this post, I will try to give you some insights on how CRM authentication works. Modification or updates to CRM authentication pipeline is not supported. This article should be for your reference purpose only.

CRM authentication framework has a pluggable modular structure. Where each supported authentication is plugged into the architecture. CRM supports different way of authenticating users based on the deployment SKU.

• On-Premise: In this deployment SKU there exists an AD in the system and the users authentication is handled seamlessly via integrated windows auth using Kerberos or ntlm.
• IFD / SPLA: This deployment SKU allows users to access their data over internet using a custom form based authentication. This style of authentication still requires an AD in the background to verify user and is used by many of the on-premise installations configured in IFD mode and as the primary mode of authentication provided by SPLA partners.
• Live: This deployment SKU is primarily used by the Microsoft Dynamics CRM online. The users are authenticated based on their Windows Live Ids.

In this post I will mainly talk with reference to the on-premise and IFD SKU authentication.

Analyzing the web.config file

Open the web.config file present on the CRM website in an editor and look at the following.

• The authentication node dictates the strategy CRM uses to authenticate users.

<crm.authentication>
    <!-- Indicates which authentication strategy should be used, strategies are stored in config DB table AuthenticationSettings-->
    <authentication strategy="OnPremise" />
</crm.authentication>

• There are two httpModules that CRM registers.

<httpModules>
    <add name ="MapOrg" type="Microsoft.Crm.MapOrgEngine, Microsoft.Crm, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add name ="CrmAuthentication" type="Microsoft.Crm.Authentication.AuthenticationEngine, Microsoft.Crm, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>

• MapOrg: This module is used only for on-premise (or IFD- internal) user request processing. The main task of this module is to get the organization name from the url (for regular http requests) or the authentication token (for sdk requests) and set it on the application context for latter use.
• CrmAuthentication: This is the main authentication module used by CRM. It accepts or rejects the request based on set of predicates and providers.

Note: These two module are not invoked in case of direct report server access, for example when you use the excel apps to refresh crm data working inside your intranet.

Analyzing the CRM authentication pipeline.

The CRM authentication pipeline is stored in the configuration database (MSCRM_CONFIG) in the AuthenticationSettings and AuthenticationSettingsProperties table.

The below query can be used to view the authentication pipeline.

select a.ConfigurationName, ap.ColumnName, ap.NVarCharColumn 
from dbo.AuthenticationSettings a, dbo.AuthenticationSettingsProperties ap
where a.id = ap.id
and ap.NVarCharColumn like '%<%'

The ConfigurationName gives the authentication strategy determined from the webconfig file and the ColumnName indicates the type of settings that can be loaded. The three types of settings possible are CrmAuthenitcation, CrmPassport and CrmPostAuthentication.

The CRM Online uses the CrmPassport authentication strategy.

Both On-Premise and IFD uses the CrmAuthentication type settings.

IFD has an additional CrmPostAuthentication type settings (pipeline step).

Below is an extract for the pipeline xml used for on-premise CRM system.

<?xml version="1.0"?>

<pipeline xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <step>

        <predicate type="Microsoft.Crm.Authentication.UrlPathPredicate, Microsoft.Crm, Version={0}, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

            <configuration key="pathSdk2007" value="/MSCRMServices/2007/CrmService.asmx" />

            <configuration key="pathSdk2007MetadataService" value="/MSCRMServices/2007/MetadataService.asmx" />

            <configuration key="pathSdkInternalMetadataService" value="/MSCRMServices/Metadata.asmx" />

            <configuration key="pathSdkInternalMetadataService2009" value="/MSCRMServices/2009/Metadata.asmx" />

            <configuration key="pathSdk2009" value="/MSCRMServices/2009/CrmService.asmx" />

        </predicate>

        <predicate type="Microsoft.Crm.Authentication.HttpMethodPredicate, Microsoft.Crm, Version={0}, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

            <configuration key="method" value="POST" />

        </predicate>

        <provider type="Microsoft.Crm.WebServices.Crm2007.MultipleOrganizationSoapHeaderAuthenticationProvider, Microsoft.Crm.WebServices, Version={0}, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

            <configuration key="authenticationType0" value="0" />

        </provider>

    </step>

    <!-- ommitted for brevity -->

</pipeline>

We can see that CRM authentication pipeline is a series of steps each having a set of predicates and a single provider. The predicates decide if the provider is to be applied or not.

The predicates implement the IAuthenticationPredicate interface.

namespace Microsoft.Crm.Authentication
{
    public interface IAuthenticationPredicate
    {
        void Configure( IDictionary<string, string> configuration );
        bool Evaluate( HttpApplication application );
    }
}

The providers implement an IAuthenticationProvider interface.

namespace Microsoft.Crm.Authentication
{
    public interface IAuthenticationProvider
    {
        /// <summary>
        /// Authenticate an HttpRequest on a specified HttpApplication.
        /// </summary>
        /// <param name="application">An instance of HttpApplication.</param>
        /// <returns>True to indicate the authentication is handled and stop authentication pipeline, false otherwise.</returns>
        bool Authenticate( HttpApplication application );

        void Configure( IDictionary<string, string> configuration );
    }
}

Each predicate and a provider can have configuration parameters specified as key value pairs as shown in the example extract above.

The authentication step also implements the IAuthenticationProvider interface.

Thus, when a request is received, it passes through the asp.net authentication and then reaches the CRM authentication pipeline. The CRM authentication pipeline calls Authenticate() for each registered step which in-turn calls the Evaluate() on each registered predicate. All predicates need to be evaluated before the registered provider can be executed. If any of the predicates returns false the steps execution is halted and pipeline proceeds with the next step and if all of them return true then the registered provider is executed i.e. the Authenticate() method on the provider gets called. There can only be one provider per step. If the provider returns a true then it implies that the request is handled and authentication succeeded, the pipeline execution stops else the processing continues with the next step.

CRM ships with some built in predicates and providers. Below is the list of some of them with their description.

Built in predicates.

• Microsoft.Crm.Authentication.UrlPathPredicate: This predicate evaluates if the current application request path is present in the specified list of paths passed to it via the configuration (key value pair).
• Microsoft.Crm.Authentication.HttpMethodPredicate:This predicate evaluates if the current application request httpMethod is equal to the method specified in its configuration.
• Microsoft.Crm.Authentication.AlwaysAuthenticationPredicate :This predicate always evaluates to true.
• Microsoft.Crm.Authentication.ServerRolePredicate: This predicate evaluates if the current server role i.e. where the application request is being processed, is present in the role mask specified to it in its configuration.
• Microsoft.Crm.Authentication.CookieExistPredicate: This predicate evaluates if the CRM authentication cookie is present it the current application request. It checks for a cookie with name “MSCRMSession” and checks for the presence of value “ticket” inside it.
• Microsoft.Crm.Authentication.InternalRequestAddressPredicate: This predicate evaluates if the current application request user host address is a loopback address or within the IP address range specified in the registry key “IfdInternalNetworkAddress”.
• Microsoft.Crm.Authentication.ExternalRequestAddressPredicate: This predicate is the opposite of the above predicate.

Built in providers:

• Microsoft.Crm.Authentication.PassThroughAuthenticationProvider: This provide always returns true, indicating the authentication succeeded.
• Microsoft.Crm.Authentication.RejectAuthenticationProvider: This provider always returns false, indicating the authentication failed.
• Microsoft.Crm.Authentication.WindowsAuthenticationProvider: This provider is used to authenticate users based on their window identity for a specific organization.
• Microsoft.Crm.Authentication.AnyOrganizationWindowsAuthenticationProvider: This provider is used to authenticate users based on their window identity. The user could be a CRM user in any of the CRM organization in that deployment.
• Microsoft.Crm.Authentication.ConfigDBWindowsAuthenticationProvider: This provider is use to authenticate users to the configdb via their window identity.
• Microsoft.Crm.Authentication.CrmPostAuthenticationProvider: This provider is used to authenticate IFD users via the CRM authentication cookie present in the request. The CRM authentication cookie is set when the user logs in by providing the username and password via the signin page.
• Microsoft.Crm.Authentication.RedirectAuthenticationProvider: This provider redirects all requests to another page specified to it via its configuration.
• Microsoft.Crm.Authentication.CrmServiceRedirectAuthenticationProvider: This provider redirects all requests to CrmServiceWsdl.aspx.
• Microsoft.Crm.Authentication.IfdRedirectAuthenticationProvider:This provider redirects all requests to the singin.aspx page on IFD.
• Microsoft.Crm.Authentication.RejectAuthenticationProvider: This provider rejects all application requests.
• Microsoft.Crm.WebServices.Crm2006.SingleOrganizationSoapHeaderAuthenticationProvider: This provider authenticates users based on the soap header for sdk calls on the 2006 endpoint. It authenticates the user to the default organization for that user.
• Microsoft.Crm.WebServices.Crm2007.MultipleOrganizationSoapHeaderAuthenticationProvider:This provider authenticates users based on the soap header for sdk calls on the 2007 endpoint. The user specifies the organization inside the soap header to which he/she wants to authenticate.
• Microsoft.Crm.WebServices.Crm2007.CookieAndSoapHeaderAuthenticationProvider: This provider can handle both soap and http request authentication. It extracts the CRM authentication token from a soap header for sdk calls (or) from the cookie present on an web request and authenticates based on it.

365blog

See more articles from this author