Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at info@xrmforyou.com
Off late I have been getting loads of queries regarding this topic and whenever I get this one, I always provide the below link
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c
However more often than not I find them coming back saying that even though they followed the entire documentation, they really could not make it work.
So finally I sat down went through the entire documentation, unraveled all the confusions and putting down this blog in the interest of my blog readers and community. I will keep it very simple with the minimal stuffs to make it work.
So let’s get started.
The first step is create a Azure AD B2C tenant. Please note you would need a valid Azure subscription to create a B2C tenant. I won’t explain the process here. It’s detailed in here.
https://docs.microsoft.com/azure/active-directory-b2c/active-directory-b2c-get-started
I create a Azure AD B2C tenant. Also I configured Customer self service portal. Details below
B2C tenant domain – xrmforyoub2c.onmicrosoft.com
Portal Url – https://powerappsyou1.microsoftcrmportals.com
Step 1: Register the Portal application in Azure AD B2C
Open your Azure AD B2C tenant
Click on Applications and Create a New application
Enter the details of the application as below
Name can be anything you want. I have put it as “Xrmforyou CRM Portals”.
Application type is Web App/ Web API
Set Allow Implicit flow = Yes
The final one is the reply URL – put it in the format of <portal url>/signin-<provider name>
Here in comes the main confusion. What is the provider name? Well you can say provider name is just a name you provide to identify your Login. I intend to use the phrase for the tutorial – “Azue AD B2C”. Reply URL here for me is <portal url>/signin-azure-ad-b2c (spaces replaced by –)
Once you save the application, you get a GUID In the application Id field. Copy and store it somewhere. We would need it soon.
Also copy the Reply URL. We are going to need it as well.
Step 2: Set up a user sign in policy in Azure AD B2C
Azure AD B2C is essentially an identity provider. Here you can define a User Policy which basically provides the identity provider, the claims and user attributes. It’s basically a way to define the identity provider which would validate the login, the attributes the user need to provide during the login process and the claims that will be passed to the application once the user successfully logs in.
In your Azure AD B2C tenant, select User flows (policies)
Click the “+” sign to create a New Policy
Select “Sign up and Sign In” from the below menu.
Enter a name and then in the Identity provider select “Email signup”. This basically allows the user to sign in/ sign up with their email addresses.
As we scroll below, comes one of the most important part of this process and that is selecting the User attributes and claims.
Before we go ahead and select some from the list, lets understand that when we think from the portal perspective, the important attributes when a user sign in are First Name, Last Name and most importantly the Email Address
So we will set up this policy in such a way so that when a user sign up using this policy in the portal, First Name, Last Name and Email address are automatically mapped to the newly created contact in CRM.
User Attributes are the one which are collected from the user when the user signs up first time in the portal
If you observe carefully, apart from First Name, Last Name, Email in the user attributes we have selected City, Country/ Region as well. We won’t be mapping them to the contact as of now but just to show that you can throw those up in the sign up page. We will see it in a short while.
Claims are the values about the user returned to the application once the user has successfully signed in. Here I just map GivenName, Surname and Emailaddresses (collection)
Go ahead and save the flow before we proceed with other stuffs.
Once the User flow is saved, Click on Properties
Navigate to the section “Token compatibilty Settings” and in the Issue claim, select the URL with tfp. Save the user policy.
The final step is to Run User flow
Click on the Metadata Endpoint as highlighted below
It will open the JSON definition of the end-point from where you need to copy issuer endpoint as highlighted below
Copy it and store it somewhere. We would need it later.
Step 3: Set up Site settings in Dynamics 365 Portal
So here we are in Step 3. And we really have done a lot through before reaching here. What we will do here?
If you remember, in the course of our journey we have collected three jewels along the way. One was the application id when we registered the portal in Azure AD B2C. Next is the reply url of the application. And the last one is the issuer id of the User policy from the previous step. We are going to need all those now.
So let’s get started
Go to your CRM –> Portals –> Site settings
Create the below records. Observe I have the phrase “Azure AD B2C” in the settings Name. This is nothing but the unique provider name (which can be any name as I stated earlier)
Record 1:
Name: Authentication/OpenIdConnect/Azure AD B2C/Authority
Value: <issuer url of the policy>
Record 2:
Name: Authentication/OpenIdConnect/Azure AD B2C/RedirectUri
Value: <Reply url you configured while registering the application in Azure AD B2C>
Record 3:
Name: Authentication/OpenIdConnect/Azure AD B2C/ClientId
Value: <client id of the registered application>
The next set of site setting records need a bit of explanation. In our previous step when we created the User flow (policy), I explained you the user attributes and claims. Once the user signs up for the first time, the information captured in the user attributes are passed to portal as claims. But once the portal receives those claims, it should know which fields it should map to. The below site setting takes care of this.
Record 4:
Name: Authentication/OpenIdConnect/Azure AD B2C/RegistrationClaimsMapping
Value: emailaddress1=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress,
firstname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname,lastname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
As you can see, I have mapped the claims email, givenname and surname to emailaddress1, firstname and lastname fields of the contact respectively. To know more about claims and format please visit the below link. But for this tutorial, I hope this is pretty clear.
If you want to map values even during sign-in, you just need to add another site setting record here.
Name: Authentication/OpenIdConnect/Azure AD B2C/LoginClaimsMapping
Value: emailaddress1=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress,
firstname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname,lastname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Now as the user signs up to the portal using their email, it creates a contact record in Dynamics. Next time if there is another user sign-in with the same email, we should not be creating a new contact. We should associate the new sign-in to the existing contact. The below site setting will take care of this.
Record 5:
Name: Authentication/OpenIdConnect/Azure AD B2C/AllowContactMappingWithEmail
Value: true
Finally one are at the last site setting. And this is not mandatory one. But if your goal is that authentication through this Azure AD B2C should be the only way the user authenticates with the portal and no other method of sign-in is allowed, then the below site setting does exactly that.
Record 6:
Name: Authentication/Registration/LoginButtonAuthenticationType
Value: <your issuer url from the user flow>
All set-up and done. Now with the final test.
I browse my portal and click on Sign In.
This is the login page I get. As you can see, with the last site setting, we have disabled all other methods of registration.
In the above screen, we have two options. One to sign in and the other to sign up. Let’s first click on sign up.
We get the below screen.
So what are these fields. If you remember correctly, these are the same fields we selected as attributes in the User policy.
Once I complete my login process, I get the values mapped from claims for email, firstname and last name.
Awesome isn’t it.
Hope this finally gets it working for you.
Debajit Dutta
(Dynamics MVP)
For consultation/ corporate training visit www.xrmforyou.com or reach out to us at info@xrmforyou.com
Our product offerings:
Role based views for Dynamics 365 (http://www.xrmforyou.com/role-based-views.html)
CRM-Sharepoint Attachment uploader and metadata manager (http://www.xrmforyou.com/sharepoint-integrator.html)
Record Cloner for Dynamics 365 (http://www.xrmforyou.com/record-cloner.html)
Multiselect picklist for Dynamics 365 (http://www.xrmforyou.com/multi-select-picklist.html)
Discover more from Debajit's Power Apps & Dynamics 365 Blog
Subscribe to get the latest posts sent to your email.
Thanks for the info Debajit,
Does this mean that we do not have to add each user as a guest login in Azure AD like your previous post on authentication? Ideally we would like to not create guest accounts in our AD.
Thanks