Before we do a deep dive into Azure Active Directory Connect, I want to spend some time on Microsoft’s Azure Business-To-Consumer (B2C) feature. Behind all the marketing hype, B2C is essentially an external security token service (on steroids) that is integrated with Azure Active Directory. In addition to the standard role of producing security tokens, the service provides self-service provisioning, self-service password reset, and profile editing. All of these features are packaged into an easy solution that can be integrated into native and web apps. If you’d like to learn more, please check out the Microsoft documentation. With the short intro out of the way, let’s start digging in.
So you aren’t a developer but you’d like to understand how these features work and what business problems they could solve for your customers or clients. In comes PowerShell. For those of us who have limited to no developer experience, PowerShell provides a means to experiment with these features. With a few simple lines of code, we can test out the self-provisioning feature of B2C.
In this scenario, we will be running a sign-up policy, emulating a native app, and using LinkedIn as our IdP. Follow the steps below to setup the sample application:
- Create a B2C Directory
Our first step is to create a B2C directory in Microsoft Azure. This is done through the classic management portal within Azure. Go through the standard process of creating a directory instance and ensure you check the box This is a B2C directory.
- Register B2C at Linkedin
Before Microsoft’s B2C feature can obtain information from LinkedIn, it must be registered. Applications can be registered with LinkedIn at https://www.linkedin.com/secure/developer. During the first portion of the registration you’ll be prompted to enter some information about the application name, description, and the like. Enter whatever you’d like, it’s not important.On the next screen, you’ll be given your client ID and client secret. This information should be treated the same way you treat any of your credentials. Don’t accidentally post it to the Internet like so many developers do. You also need to add an authorized redirect URL. This will be in the format of https://login.microsoftonline.com/te/<tenantID>/oauth2/authresp. See the screenshot below for an example.
- Add LinkedIn as an IdP in Azure
Your next step will be to configure LinkedIn as an IdP within Microsoft Azure. This is done through the new management portal in Azure. After you login, you’ll want to change your directory instance by clicking the user icon in the top right hand corner of the screen and selecting your new B2C directory. From there, search for the B2C blade and hit the settings button (the gear icon).Select the Identity Providers node and click the Add button. Enter the name LinkedIn, select LinkedIn from Identity provider type, and from the Set up this identity provider enter the client ID and client secret obtained from LinkedIn. Hit the save button and move to the next step.
- Register your application with Azure B2C
Now it is time to register our imaginary application with Azure B2C. From within the B2C settings blade, select the Applications node and click the add button. Enter a name for the application, ensure the Native client option is set to Yes and copy the redirect URI. Click the save button.After your application is registered, select it and copy the redirect URI and Application Client ID. You’ll need this information once we setup the script.
- Create a custom attribute
Here we take an optional step to create a customer attribute. We do this because we’ll examine how the attribute is presented in the access token when we cover a SignIn policy at a later date. Developers may use custom attributes to gather additional information to make decisions within their application. For example, during provisioning, the developer may ask the user to select the industry in which they work in. This information could then be used to customize content within the application.To create the attribute select the User attributes node and follow the prompts. I created a custom attribute named Function that users are required to populate during provisioning.
- Create a Sign-Up Policy
Now we will create our first sign-up policy. Select the Sign-Up policies node and hit the add button. Enter a policy name of B2C-1-Signup. Enter the following information for the settings listed below. Leave the rest at the defaults.
- Identity Providers – LinkedIn, Email Signup
- Sign-up attributes – Select all attributes
At this point we have registered our instance of B2C with LinkedIn, registered our application with B2C, and configured our signup policy. We’re almost ready to do some PowerShell scripting. Before we can get into the scripting, we need to download the beta ADAL .NET libraries from nuget.
You’ll want to download the nuget command line utility 3x. It’s a simple standalone executable we will use to download the appropriate the ADAL library from Nuget gallery. Once the command line utility is downloaded, open a Windows command prompt and run the command belong where destination is the directory you want to store the libraries.
nuget install Microsoft.Experimental.IdentityModel.Clients.ActiveDirectory -pre -OutputDirectory destination
We’re now ready to see just how simple and powerful the B2C features are. Download the ZIP file below and extract the PowerShell script. You’ll want to open the script up and fill the necessary variables per the instructions above.
A big thanks to Shriram over at MSFT for the portion of the script that decodes the JWTs returned after the sign-up policy is successfully processes. His full script is located here.
After filling in the appropriate variables per the instructions in the script, you’ll be good to go. Remember to modify the section where the ADAL libraries are loaded with the location you saved the libraries to. When the script is run the sign-up policy will initiate and the user will be prompted to select from either an email signup (creation of a managed Azure Active Directory account) or use their LinkedIn account. See the screenshot below:
After the user opts to select their LinkedIn account, they will be prompted to log into LinkedIn and consent to B2C accessing portions of their profile information as seen in the screenshot below.
After the user authenticates to LinkedIn and consents, they will be prompted to fill in the information you configured as being required in the sign-up policy as seen in the screenshot below. Look closely and you’ll see some information has been pre-populated from information in my LinkedIn profile.
After the user fills in the required information, an OAuth bearer access token will be returned to our application (in this case our PowerShell instance). The function written by Shriram will parse the token and return the claims in the JWT similar to the screenshot below.
Within the token we see that the IdP that created the token was LinkedIn. To round it out, open up your B2C Directory in the classic management portal and you’ll see a new user object has been provisioned for the user.
What you’ve seen here is a quick and dirty way to demo the B2C functionality. Over the next few days, we’ll explore the other features including sign-in and password reset. We’ll spend more time looking at the access tokens generated with those policies.
A few things to note:
- Be careful with what Application Claims you configure in your sign-up policies. If you configure claims that aren’t provided by the IdP, Microsoft throws a really cryptic error. I ended up having to debug the issue in Fiddler. The problem that pops up is the B2C feature will make a call to the B2C directory looking for the user object to pull the additional claims. Well, that user object doesn’t exist, so instead an error is thrown.
- The experimental ADAL .NET libraries are not currently documented anywhere that I could find in the MSDN website. Thankfully I came across a link at symbolsource.org which had a nice breakdown of each function and an explanation of the parameters. You can find that link here.Enjoy!