Portal Authentication in Dynamics 365

This section will cover different types of portal authentication for Microsoft Dynamics 365, including:

Forms Authentication

Portal Authentication

Forms authentication lets you authenticate users by using your own code and then maintain an authentication token in a cookie or in the page URL. To use forms authentication, you create a login page that collects credentials from the user and that includes code to authenticate the credentials. Typically you configure the application to redirect requests to the login page when users try to access a protected resource, such as a page that requires authentication. If the user’s credentials are valid, you can redirect the request back to the originally requested resource with an appropriate authentication ticket (cookie). If you do not want the redirection, you can just get the forms authentication cookie or set it. On subsequent requests, the user’s browser passes the authentication cookie with the request, which then bypasses the login page. You configure forms authentication by using the authentication configuration element as shown in screenshot below.

authentication img 2

The form authentication is implemented in portals by maintaining the user credentials for the portal in an entity in Dynamics 365. One example of implementing forms authentication in a Dynamics 365 portal will be maintaining the credentials in contact entity in Dynamics 365 and creating a custom membership provider class using ASP.NET membership, fields created in contact entity for authentication and also using ASP.NET login controls. ASP.NET membership lets you store and manage user information and includes methods to authenticate users. ASP.NET login controls work with ASP.NET membership. They encapsulate the logic to prompt users for credentials, validate users, recover or replace passwords, and so on. In effect, ASP.NET membership and ASP.NET login controls provide a layer of abstraction over forms authentication.

Tip! Want to learn Dynamics 365 development skills?  Check out Developer Environment and Developer Extending events.

Windows Authentication

authentication img 3

Windows Authentication treats the user identity supplied by Microsoft Internet Information Services (IIS) as the authenticated user. IIS provides a number of authentication mechanisms to verify user identity, including anonymous authentication, Windows integrated (NTLM) authentication, Windows integrated (Kerberos) authentication, Basic (base64 encoded) authentication, Digest authentication, and authentication based on client certificates. This authentication method uses Windows accounts for validating users’ credentials. You configure Windows authentication by using the authentication configuration element as shown in the screenshot below.

authentication img 4

The Windows authentication is implemented in CRM portal when the portal is an intranet application by validating the user based on his/her network credentials

Windows Live ID Authentication

authentication img 5

Windows Live ID Authentication allows users to be authenticated using their windows live id to your website without having to create your own security providers. The following are the steps needed to implement Windows Live ID authentication:

Step 1: Register your website with Windows Live ID.

  1. To begin, you need to register your Website with Microsoft account:
  2. When registering your site, you need to provide your full domain name, for example, “”, not just “”.
  3. You also need to provide a URL that directs Microsoft account requests back to when they have finished signing in. This will be to your Handler Service, which you can read about later in this document, but, by default, the URL to enter is:
  4. After you have registered your Website, it provides you with an application ID and a secret that you will use to plug into your web.config so that the site can be hooked up to the Microsoft account.

Here are some things to note:

  • Your domain names cannot include strings such as localhost,, or anything with the word “live” in it.
  • You cannot share the management of the Website with other users.
  • You cannot change your domain name after you have registered it.

Step 2: Add Live ID Information to the web.config

In your web.config, under Connection Strings, you will need the following string populated with your Application ID and Secret:

<add name=”Live-ID” connectionstring=”Application Id=???; Secret=???” />

Step 3: Add the Membership Provider and Handler Service

The Membership Provider handles the user login information. Using Microsoft account requires the use of the Microsoft account Membership Provider:

<membership defaultProvider="CrmMembershipProvider">
<add name="CrmMembershipProvider" type="Microsoft.Xrm.Portal.Web.Security.LiveIdMembershipProvider, Microsoft.Xrm.Portal" liveIdConnectionStringName="Live"/>

The Handler Service validates whether the authenticated user has been registered on your Website. If you are running an Internet Information Services (IIS) 7 site in Integrated Mode, you will need to ensure that the following is added in your <handlers> section:

<add name="LiveId" verb="*" path="LiveID.axd" preCondition="integratedMode" type="Microsoft.Xrm.Portal.Web.Handlers.LiveIdWebAuthenticationHandler, Microsoft.Xrm.Portal" />

If you are running in Classic Pipeline Mode or IIS6, the Handler Service is configured under the <httpHandlers> section of your Web.config file.

<add verb="*" path="LiveID.axd" type="Microsoft.Xrm.Portal.Web.Handlers.LiveIdWebAuthenticationHandler, Microsoft.Xrm.Portal"/>

Step 4: Add the LiveIDLoginStatus Control

The last step is to add the LiveIdLoginStatus control, which works like the LoginStatus control. It displays a log in link for users who are not authenticated and a log out link for users who are authenticated.

When anonymous, the link takes the user to Windows Live or optionally (using LoginNavigateUrl) to a specified landing page that lets the user know they are going to Windows Live.

When authenticated, the log out link resets the current user’s identity to be an anonymous user.

<crm:LiveIdLoginStatus runat="server" />

This assumes that the “crm” tag prefix has been registered to “Microsoft.Xrm.Portal.Web.UI.WebControls“.

Force Registration

When using windows live ID for authentication, only the Passport Unique Identifier (PUID) is known. If you want additional information about the user (such as a display name or email) you will need to collect this from the user. Two common ways to do this are:

  • Set up a page for them to fill in their information at their own convenience when they are logged in.
  • Collect information before they can be authenticated on your site.

To do the second way, your Microsoft account setup will need some special handling.

1. As part of a user registration, Microsoft Dynamics 365 needs to know the PUID of the user so that it can link this to the user’s Microsoft Dynamics 365 contact information. In other words, you need to have the user log in using Microsoft account and then send the user to your registration page. This is done by adding the RegistrationUrl attribute on the LiveIdLoginStatus control.

<crm:LiveIdLoginStatus runat="server" RegistrationUrl="/CreateUser" />

2. In the code behind of your registration page, you need to add code to keep the Microsoft account token and create the new user once you have collected the information you want.


protected void Page_Load(object sender, EventArgs e)
  if (InvitationCode == null || InvitedContact == null)
    var page = SiteContext.Current.Website.GetPageBySiteMarkerName("Home");

  // Add the Live ID variables that come from the authentication handler to hidden
  // script variables.
  if (Request["live-id-action"] == "register")
      Request["live-id- token"]);

Windows Azure Authentication

When you want to create an external facing portal which will be used by internal CRM users where their CRM is non-IFD that will not be accessed externally and also will be used by external users it is recommended to use windows azure authentication so that for external users no need to create and maintain new username names and passwords and they could use their CRM account to authenticate to the portal.

The high-level steps needed for Windows Azure authentication are as follows:

  1. Deploy the portal in the windows azure cloud. For more details on how to deploy an application please refer to below links:
  2. Register the web app in your Windows Azure AD tenant. Once the app is known, Windows Azure AD will accept users’ requests to authenticate against it.
  3. Add something in front of your app, so that a) unauthenticated requests can be blocked and redirected toward the correct Windows Azure AD tenant for user authentication, and b) users who authenticated with Windows Azure AD can be recognized and granted access.

For more details on Windows Azure Authentication, please refer to

Authorization Roles

When implementing authorization in portal depending on what users access the portal we can either create authorization roles in the portal or use the authorization roles in CRM. Here are some sample scenarios that help us on how to implement authorization in portal

  • If at all the portal will be accessed by Dynamics 365 users where their Dynamics 365 is not IFD and need to perform any of the CRUD operations on Dynamics 365 Data through the portal when they are outside their network then the portal can inherit the Dynamics 365 authorization roles.
  • If external users (non-Dynamics 365 users) need to access the portal for example consider portal that deals with cases that have different users  like where an admin has to see and perform operations on all data, a case manager can see only the related clients data, and perform operations only on the associated clients data, the logged in client can see, access only his/her data we have to create authorization roles in portal.

It’s important to properly create the required security roles at both a Dynamics 365 and Application level when developing a portal.  Dynamics 365 roles can determine the individual user access to Dynamics 365 data and the application level authorization can determine what users have access to in the portal.  It’s not uncommon for a portal to utilize one security role that has a high level of access but utilizes impersonation in order to mimic the security restrictions of individual users identified in the system.  Generally when accessing Dynamics 365 Data and performing any of the CRUD operations on Dynamics 365 data from a portal we create a service account and add the service account as a user in Dynamics 365 with the required role and use this user to connect to Dynamics 365 from a portal and perform CRUD operations on Dynamics 365 data from a portal. In some cases, we will need to implement impersonation. For example, consider an intranet portal that is being used by internal users where the owner of the records being created must be the user creating the record instead of the service account then we need to implement impersonation. (For more information on how to implement impersonation refer to

Business Rules and Server-Side/Client-Side Validations

Care should be taken to identify where the business logic of a portal will live.  While it can be useful to enforce business rules on entities in Dynamics 365, it might not be the best fit for users who are accessing a custom application.  Client side validation allows for some checking to occur without resources being utilized from the server.  This not only has a positive impact on the utilization of your server’s resources, but it also creates a better user experience because of the speed with which responses are generated.  Server side validation or error checking can improve the user experience by handling things like a loss of connection to Dynamics 365 or data as well as things like duplication of records.  Server side validation is usually more intensive from the server’s perspective but allows for portals to handle lower level exception handling.

Authentication Guidance

Here are some guidelines to help make decisions on which portal authentication you should use:

  • If you do not need to write any custom authentication and want to use Window accounts, you may want to use Windows Authentication.
  • If you want to have custom authentication with different criteria, or you do not want to tie your application to the Windows accounts, you may want to use Form Authentication.
  • If you want to integrate Windows Live ID into your websites to run a broad range of web server platforms, you may want to use Windows Live ID Web Authentication.

Do More with Dynamics 365

Expand your knowledge of Dynamics 365 through PowerObjects’ educational blogs.  Looking to learn in a more formal setting?  Check out our in-person training courses.

Want to learn development skills?  Check out Developer Environment and Developer Extending events.