Configure Azure AD B2C For Customization
Azure Active Directory B2C is a powerful identity management solution that brings a lot of power to customize and brand an identity management solution quickly. But to implement the best solution, you have to learn to play outside of the box where the real power exists. By using the power of custom policies, you can control the sign up and sign in flow, implement custom flows such as profile editing, linking social media accounts to an identity, or even deleting a user account at a user’s request. You can also invoke custom functionality exposed by HTTP APIs or Azure Functions. In this post, we’ll take a step in the direction of using custom policies by configuring our Azure Active Directory B2C tenant for customization.
This is the second post in a series documenting how to use Azure Active Directory B2C to implement a custom identity management solution for a Software-as-a-Service application. If you are new to this series, I recommend you review the first post.
Step 1: Create a Test Application
In the rest of this series, we are going to be crafting, iterating, and modifying custom policies that will control how our Azure Active Directory B2C tenant manages identities, creates new users, logs in users, updates user profiles, and other actions. Each post (after this one) will present a problem, challenge, or improvement to our identity solution and we’ll implement it. A big part of each post is going to be testing to see whether the change works and diagnosing (and hopefully solving) any problems that we discover. In order to test our customizations, we need a test application that we can use to sign up, sign in, and perform other user activities on behalf of. Don’t worry. Setting up the test application is entirely based on configuration. We will not need to deploy anything to the cloud just yet.
To create a test application, we’ll first need to log into the Azure Portal and then switch to our Azure Active Directory B2C tenant. Once there, open the Azure Active Directory B2C console.
In the navigation list on the left side of the portal, select App registrations. This link will open the list of registered applications and will allow us to add a new application for testing.
On the top menu bar, click the New registration link. This will open a form for creating a new client application for the B2C tenant. A client application uses the OAuth 2 or OpenID Connect protocols to log a user in using B2C and obtaining the identity and access information for the logged in user. Microsoft provides a test website hosted at https://jwt.ms that we will use for testing. After the user logs into the B2C tenant using a web browser, the web browser will be redirected to https://jwt.ms and we will be able to view the JWT identity or access token that was output by Azure AD B2C.
For the Name field, I am going to use Test to indicate that this application is for testing. For the Supported account types field, I will use the default selection of Accounts in any identity provider or organizational directory (for authenticating users with flows). In the Redirect URI field, I will set the platform to Web and will enter https://jwt.ms in the URI field. I will also ensure that the Grant admin consent to opened and offlineaccess permissions checkbox is checked. Finally, I will click the Register button to register the test application with my B2C tenant.
I do not at this point need to create a client secret or make any modifications to the test application because I will be testing through the Azure Active Directory B2C console.
Step 2: Register Custom Policy Applications
When using custom policies with Azure Active Directory B2C, there are two other internal applications that will interact with the B2C tenant for managing local accounts (for password-based authentication). IdentityExperienceFramework is a web API that exposes operations for managing local accounts. ProxyIdentityExperienceFramework is a native application that uses delegated permissions to invoke the web APIs exposed by IdentityExperienceFramework. Just like the test application, we do not need to deploy anything. The functionality exists within Azure AD B2C. We only need to activate and expose it.
Before we can register these applications with the B2C tenant, we need to create policy keys used by the applications. A policy key is basically a secret value that is stored security by the B2C tenant and only exposed when needed by a custom policy or application running inside of B2C. A policy key could be an X.509 v2 certificate, a cryptographic key, an API key, a password, or some other value that is sensitive and needs to be kept a secret. Policy Keys can only be used in combination with custom policies.
For the applications to work, we need to generate two cryptographic keys. The first key will be used to generate or validate digital signatures. The second key will be used for encrypting sensitive data in the directory.
Back in the Azure AD B2C console, click on Identity Experience Framework on the left navigation list. On the Identity Experience Framework page, click Policy keys in the left list.
Click the Add button on the Policy keys top bar. This will open a form on the right side of the portal. For the Options field, keep the value set on Generate. In the Name field, enter TokenSigningKeyContainer for the name of the signing key. The full name will be changed to B2C_1A_TokenSigningKeyContainer. B2C will add the B2C_1A_ prefix, so you do not need to worry about it. For the Key type field, choose RSA as the cryptographic algorithm. For the Key usage field, ensure that Signature is checked. Click the Create button to create the signing key.
Click the Add button again on the Policy keys top bar to create the encryption key. Ensure that the Options field is Generate again. In the Name field, enter TokenEncryptionKeyContainer. Set the Key type field to RSA, and change the Key usage field to Encryption. Then click the Create button to generate the encryption key.
Now in the list, you will see both of the keys that you just created:
In the navigation menu on the left, choose App registrations again and create a new app registration. In the Name field, enter IdentityExperienceFramework. In the Supported account types field, choose Accounts in this organizational directory only. For the Redirect URI field, choose Web and enter the URI https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com. For my development tenant, the URI will be https://projectcenterdev.b2clogin.com/projectcenterdev.onmicrosoft.com. Also make sure that the Grant admin consent to opened and offlineaccess permissions checkbox is checked. Create the application.
On the next page that is shown for the application after the registration completes, click the Expose an API menu item from the list on the left. In the Expose an API page, choose Add a scope. In the view that appears, go ahead and just accept the default Application ID URI that is generated for you. In the next view, you will enter the API permission information.
For the Scope name field, enter user_impersonation. In the Admin consent display name field, enter Access IdentityExperienceFramework. In the Admin consent description field, enter Allow the application to access IdentityExperienceFramework on behalf of the signed-in user.Add the scope.
Return to the App registrations page and add another app registration. In the Name field, enter ProxyIdentityExperienceFramework. In the Supported account types field, choose the Accounts in this organizational directory only field. For the Redirect URI field, change the platform field to Public client/native (mobile & desktop) and set the URI to myapp://auth. For Permissions, ensure that Grant admin consent to opened and offlineaccess permission is checked. Register the application.
In the application page, click the Authentication link in the left list. Scroll to the bottom of the page if necessary and in the Allow public client flows section, enable mobile and desktop flows and save the change.
In the left list, choose API permissions and click on Add a permission. In the Request API permissions, change to the My APIs view, and select the IdentityExperienceFramework API. Chose the userimpersonation permission and add the permission. Click the Grant admin consent button and confirm the permission.
Congratulations! Your Azure Active Directory B2C tenant is now ready to start being customized using custom policies!
Where Do We Go From Here?
This post covered a tedious chore: setting up the Azure Active Directory B2C tenant for custom policies. But this necessary process has unlocked the doors for us to do some really cool things using our Azure Active Directory B2C tenant. We’re not yet quite ready to customize anything though. In the next post, we’ll set up a basic sign up or sign in flow using local accounts managed by our B2C tenant. I will really start to explain how custom policies work so that you understand how they are structured and how they work. Once we get a basic flow working, we will start iterating on the flow and customizing it by adding some custom password validations and multi-factor authentication.
