If you read the Microsoft documenation for PowerApps Portals (and you do read it, right?) it states that the preferred method for user authentication for the PowerApps Portals is Azure AD B2C (Business to Consumer).
The big benefits is that it takes a lot of the administration of handling passwords and authentication out of the hands of portal managers and also provides some options when building portal companion apps.
Microsoft documentation describes the steps to configure Azure AD B2C for portals and there are also a lot of great blog posts (see below) that describe and talk about the process from a Dynamics 365 for Portals perspective.
It had been a while since I went through the process. I decided today to specifically setup Azure AD B2C on the new PowerApps Portals preview and I ended up taking a lot of screenshots and notes. So this post is really just meant for me (or rather my future self) on how to setup Azure AD B2C for Portals.
Thanks to other community folks for their excellent posts on this topic, which helped me put my own notes together:
Setup Azure AD B2C
You will require an Azure subscription. You can setup a free account and Azure AD B2C should not cost you anything if you have a reasonable number of logins.
Sign into the Azure Portal on which there is a subscription attached.
Click to Create a resource (upper left corner) and search for “Azure AD B2C”
Click “Create” to create the Azure AD B2C resource.
There will be two options, one to create a new Azure AD B2C Tenant and another to link the tenant to your Azure subscription. The first step is to create the tenant.
Create an organization name and a domain name. I followed a pattern of <<orgname>> and <<orgname>>tenant, but ideally put in something descriptive.
Ideally, place the Azure AD B2C resource in the same geography as your PowerApps Portal and CDS environments to reduce any potential latency issues.
After these items are setup, the Azure AD B2C tenant needs to be linked to the Azure Subscription. Click on the “Link an existing Azure AD B2C Tenant”
The Azure AD B2C Tenant should appear in the drop down list, as well as the available subscriptions. Choose to create a new resource group, and again, choose the same region as your Portal/CDS environments.
Setup Azure AD B2C Application
The next step will be to setup the Azure AD B2C Application for our portal. The first thing is to change the directory to ensure that you are logged into the Azure AD B2C tenant that you created earlier. Click on the upper right corner on your account to switch directories.
On the left panel, choose “All Services” and then search for “Azure AD B2C”. Select it from the list of services that appear.
The Azure AD B2C service page will appear with the various options.
Click on “Applications” in the Manage section and then choose “Add” to add the new application.
When setting up the application, you can pick any name but ideally it should be something descriptive. Make sure that web api and allow implicit flow are turned to “yes”. The reply URL will be your portal URL, appended with a signin-<<unique federation name>>. For my purposes, the <<unique federation name>> is “B2C” and we will need to be consistent with this in other areas of the configuration (more below).
Click Create and then the application should be setup.
Setup Policies
The next step is to create user flows (policies). These are configurable options that will drive the user sign-up and sign-on experiences while accessing the portal as well as how the password reset will work.
On the left panel, choose “User flows (policies)” from the Policies section and in the main window click on “New user flow”
We will first use the “Sign up and sign in” type. We need to define how a potential portal user will actually sign up and also sign in to the portal.
Give the policy a descriptive name. For identity providers, at this point the only option will be email signup (there are a lot of other blog posts if you want to use other identity providers). For now we will also not worry about multifactor authentication.
Scrolling down, under the 4. User Attributes and Claims section, choose at very least email address, but ideally pick Given name and Surname as well. Typically we will manage most of the user information on our portal itself that will be linked to the contact record in CDS. Click Create.
We should now have our signup and signin user flow created.
Click on Properties on the left pane, and in the main window, scroll down to the Token compatibility settings and changes the Issuer (iss) claim to option with “tfp” in the URL;
We will need to setup another user flow to configure the password reset options. This is critical if you don’t want to have spend time providing users with new passwords to the portal. This will provide a secure, self-service method for your portal users to manage passwords on their own.
Provide a descriptive name and also choose the option to reset a password using an email address.
In the claims section, choose Given Name and Surname, mainly for consistency with the signon process.
There should be two user flows listed under the application.
Keep the Azure portal open for the next steps because we will need to refer back here to grab specific settings for the portal configuration.
Settings Required for Portal Configuration
Before we can configure the portal, we need to capture some of the information.
Application Name and Application ID
We need to note a series of setting such as the Azure AD B2C application name and application id, as well as issuer URLs. The name is what we defined earlier and the application id will be a generated GUID. These can be found under the applications list.
These values will be used to update the following Portal Site Settings (see section futher down on how to update site settings)
- Authentication/OpenIdConnect/[Federation-Name]/ClientId
- Authentication/OpenIdConnect/[Federation-Name]/DefaultPolicyId
- Authentication/OpenIdConnect/[Federation-Name]/Authority
- Authentication/OpenIdConnect/[Federation-Name/PasswordResetPolicyId
- Authentication/OpenIdConnect/[Federation-Name]/ValidIssuers
We also need the policy sign-in URL. This can be located by opening the signup and sign in user flow we created earlier and by selecting “Run user flow” to generate the URL with JSON data.
You will also need to the password reset user flow policy name.
Also you will need a list of valid issuers. You will have already captured the policy sign in URL earlier. We will also need the Password reset issuer. This is found by opening the policy and choosing properties and running the user flow and clicking on the generated user flow link.
Configure Portal
Now that our Azure AD B2C has been configured, the next step is configure our PowerApps Portal to be able to interact with Azure AD B2C.
Navigate to https://make.powerapps.com and choose the Portal Management App from the list of apps. We will be configuring the Azure AD B2C integration by creating and updating Portal site settings.
The Portal Management app is a model-driven app that allows configuration updates to the PowerApps Portal (as all portal metadata is stored in CDS). Navigate to Site Settings.
You will need to decide on an unique “Federation Name” for your portal configuration. I simply choose “B2C” and we will use this value in the following configurations.
Create a new site setting and put the following value;
Authentication/OpenIdConnect/B2C/Authority
Enter in the policy sign-in URL you captured above from the Azure portal.
Save the site setting record and add another;
Authentication/OpenIdConnect/B2C/ClientId
Enter in the application id GUID you captured above from the Azure portal.
Save this site setting and add another;
Authentication/OpenIdConnect/[Federation-Name]/RedirectUri
This time enter in the portal URL, followed by “signin-B2C” (signin- <<federation name>>)
There are a couple more settings to round out this part of the configuration. To support a federated sign-out, add the following Site Setting;
Authentication/OpenIdConnect/B2C/ExternalLogoutEnabled
Set the value to “true“
To make Azure AD B2C the *only* indentity provider, add the following:
Authentication/Registration/LoginButtonAuthenticationType
And again enter in the Policy sign in URL from above;
At this point you will have entered in enough settings for a user to be able to sign on and sign in to the PowerApps Portal using Azure AD B2C, however, we will want to enable the password reset mechanism as well.
Create another new Site Setting,
Authentication/OpenIdConnect/B2C/PasswordResetPolicyId
Enter in the password reset policy ID that you captured above.
Tired of creating Site Settings yet? Only a few more…
Create a site setting for the valid issuers;
Authentication/OpenIdConnect/B2C/ValidIssuers
For the values, enter in the issuer URLs seperated by comma’s;
Finally enter a value for the default policy id.
Authentication/OpenIdConnect/B2C/DefaultPolicyId
Note there are other Site Setting values that can be configured for the PowerApps Portal. Verify your settings (I found that I missed the “Federation Name” a few times during my setup.)
PowerApps Portal Authentication
If everything was setup properly, you should be able to login to the PowerApps Portal using Azure AD B2C.
The Azure AD B2C will provide your users the ability to sign up securely as well as be able to reset their password.
You can rebrand the default Azure AD B2C page, instructions are on Microsoft Docs site. I may need to make notes someday so I could potentially create a blog post.
Summary
Setting up Azure AD B2C is not hard, but it can be a bit tedious. Hopefully these step by step instructions will be clear and allow you to configure this properly (again, speaking to my future self).
Cover Photo by CMDR Shane on Unsplash
Nick Doelman is a Microsoft Business Applications MVP and has many times stumbled on blog posts and community posts from his past self that has helped his current self. Nick also tends to post stuff on twitter so he can also find that in his timeline later at @readyxrm
Thanks for putting this together Nick. I was able to successfully setup a portal using Azure B2B for user authentication. I did however run into an issue that I can’t seem to resolve: When a new user registers, they are (as expected) asked to first verify their email address with a code (that seems to work). Once that’s done, they can continue the registration and provide a password with first/last name info. They then click “Create” and are presented with the error prompt, “The Email field is required” and a text field to enter in an email address. It’s odd because it’s already been provided/verified, but also, because it seems like you can type in *any* email address at this point and it will accept it and you’re signed in, possibly with a different email address than the one you were originally registered with.
Do you know what I may have missed in setup, or if this is a bug?
LikeLike
I believe I sorted out this issue, but I’m not sure I understand why. In your original screen cap where you’re setting up the claims for the signin user flow, you didn’t show “email” checked as a return claim. Once I checked that to make sure it was returned, things started working.
LikeLike
Thanks so much for the step by step. This really made things much much easier to deploy! Outstanding work.
LikeLike