This is Part Five of an eight-part blog series looking into a serverless application built using Azure components. The earlier parts of the series are available here: Part One | Part Two | Part Three | Part Four
Azure Active Directory B2C (Business to Customer) is an identity management service that enables you to customise and control how customers sign up, sign in, and manage their profiles when using an application. Azure Active Directory B2C enables these actions while protecting the identities of your customers at the same time.
When it comes to security, it is important that you not only trust it, but you trust it to stay secure. For our application, this was the first cloud hosted application the client was using and trust in the use of it was key. Therefore, we wanted to utilise a service that would keep up with the changing face of security and provide the connections needed. Our client used Office 365 so connecting with Azure Active Directory was one option, but we also wanted their clients to be able to connect with their own interfaces. Having read about Azure Active Directory B2C, this was the logical choice to use to provide secure logins across multiple providers such as LinkedIn and Facebook, or Microsoft alongside Azure Active Directory.
About Azure Active Directory B2C
Azure Active Directory B2C provides an identity and access management service which means that you can set up users and have the service manage their login. It utilises open standards such as Open ID Connect and SAML and allows users to connect using existing logins such as Facebook, Google, LinkedIn and Microsoft Accounts.
The benefits are:
- Get the latest security best practice such as Multi-Factor Authentication (MFA) with minimal code change
- Reduce the number of different logins your users need by re-using standard logins like LinkedIn or Google
- Scale to hundreds of millions of users without additional hardware
- Simple customisation to set-up for most scenarios
- Holding key information for each user in one place
- Ability to add custom providers where required
How is Azure Active Directory B2C Different to Azure AD?
The key difference is that Azure Active Directory B2C is designed for users outside of a specific organisation. Azure AD is designed to be for a specific organisation and while you can have guest users and external access, its focus is not for those external users. Azure AD B2C is designed to easily set-up new users and allow them to reset their password and link with existing accounts as well.
The other key change is around the pricing.
How is Azure Active Directory B2C Priced?
Azure Active Directory B2C is priced at two levels – per stored user and per authentication. The first 50,000 users are free and there is a low charge per user depending on the volume. Details can be seen at https://azure.microsoft.com/en-in/pricing/details/active-directory-b2c.
The difference to Azure AD pricing is that you would pay per user at a higher price, excluding the free limit. For lower levels of usage, there will be little difference but for larger user bases, Azure Active Directory B2C will be far more price efficient.
How Do You Get Started?
The first steps are where some of the confusion of Azure Active Directory B2C starts. A B2C Tenant can be created from the Azure Portal by searching for Azure AD B2C but you are greeted with two options:
You will first need to choose the first option which creates a new tenant and then you need to search for Azure Active Directory B2C again and link it to your subscription. Why is this? A very good question and not one I have been able to find an answer to!
Once you have your tenancy, you will need to create an Application for each of your apps that will connect to the Azure Active Directory B2C instance:
Finally, you set up your policies required for different processes such as Sign In / Sign Up. This allows you to determine which Identity Providers can be used (e.g. LinkedIn, Microsoft Accounts, etc), which attributes you would like to ask the user for and which of these attributes should be passed on to the applications. It also has the option to supply page customisations if you do not want to use the standard Microsoft login and profile edit pages.
The full steps for getting started are laid out on Microsoft Docs at https://docs.microsoft.com/en-gb/azure/active-directory-b2c/tutorial-create-tenant.
How Would You Work with an Angular Application?
Azure Active Directory B2C is not tied to Microsoft technologies so you can use within single page applications written for React/Angular/Vue, Java/PHP based websites, desktop applications or native mobile applications for iOS and Android. Some scenarios are better supported as there are sample applications on Github which also provide frameworks for connecting. The best of these for Angular applications is MSAL (Microsoft Authentication Library) which reduces the amount of framework code required for connecting to Azure Active Directory B2C. It is now possible to set up the configuration for most details without having to make any custom code at all. It should be noted that MSAL is officially still in preview but it is supported to be used in production environments.
What Issues Did We Encounter?
For our serverless project, it is pretty fair to say that Azure Active Directory B2C caused the biggest headaches! Microsoft Accounts are easy to set up through configuration, but if you want to allow Azure AD users to connect (especially across multiple tenants), there is a lot of XML required. To then use custom properties requires the use of the Azure AD Graph which is independent of the Microsoft Graph.
Configuring access to Azure AD tenants: To set-up an Azure AD tenant, you are required to use Custom Policies. These are still in public preview so are subject to change and the documentation has hugely improved since the project first started. You can either configure a single tenant or set up access for multiple tenants – this would be my recommendation for all scenarios as there is very little additional work and gives greater flexibility. The link outlines the full process, but I would highlight some areas:
- Make sure you have OneNote or similar to hand to copy all the different Guids and Keys that are referenced as you go through the steps and make sure that you clearly label each one.
- Go through each step carefully as missing one element is very hard to identify later.
- Make sure you complete the custom policies in Azure Active Directory B2C steps first as it notes in the multiple tenant page – it is easy to miss that it mentions this.
- For Azure AD integration, use the SocialAndLocalAccounts section of the Starter Pack but ignore the parts around Facebook – you can leave empty values but do not delete as there are some dependencies.
- When you have completed the custom dependencies part, do test the upload to the Identity Experience Framework before proceeding – an error here can be hard to debug later on.
- Carefully check your Object IDs and your Application IDs – it is very easy to confuse the two when pasting into the XML.
- Check in your config files to source control and check in often – it is much easier to roll back that way.
Test all these once you have completed before you start adding any custom properties, and test that this all works within your application as well.
Custom Properties: As shown in the image above, it is easy to add custom properties to the UI. Unfortunately, this will not work for the Custom Policies needed when using Azure AD, so if you want to add Custom Properties you will need to build them in to your configuration files. Also, be aware that to access the custom properties, you will need to use the Azure AD Graph which is different to Microsoft Graph. Each custom property is set up with an extension id which will change in each environment.
If I was starting from scratch, I would keep more of the user properties in the database and use the userID stored in B2C to link to that. This would ensure that info could only be returned for that user, keeping the application secure, but reducing the pain of custom properties.
Logging…Or Lack of: There is very little detail in the portal when something has gone awry, so you will need to ensure that you have App Insights set up with your application to handle it well. You will also need to write your own custom GUI for viewing the custom properties as the Azure Portal will not display them at all. Alternatively, you can use Postman and set up custom projects to return the data – this is the route we took as we already had a testbed for the Azure Functions API.
Multiple Admins for the Azure AD B2C Environment: I will confess that there is likely an answer to this one, but we didn’t find it in the time available. While admins for your Azure tenancy will be able to manage the Azure Active Directory B2C tenancy, it did not seem possible to have other users set as an admin. I am hoping this was an error on our side, but it proved pretty frustrating.
Summary
The ability to remove management of security layers from part of the application development and to have elements of control in the Azure Portal along with the rest of our virtual infrastructure was very welcome. It has ensured that our application utilises standard security technology and that it will remain secure as Microsoft continues to invest in Azure Active Directory B2C. However, there was more pain than expected and any deviation from the standard way of doing things was met with very complex work required and (at least in the early days of the project) limited documentation on how to do it. As a total cost of ownership, B2C is still a better choice than creating your own security layer but it is not as simple as it could be and you should leave plenty of time for issues encountered along the way.
TL;DR
Azure B2C fits certain scenarios for identity and access management very well allowing app developers to give users options to login speedily and easily. However, it quickly becomes very complex to extend with custom properties and non-standard providers (strangely including Azure AD). Make sure you understand the authentication standards to debug connections and be prepared to trial and error with custom XML if you are using a non-standard provider. Read details in section above of “What issues did we encounter?”.
By Kevin McDonnell, Senior Technical Architect at Ballard Chalmers
UPDATE: The next in the series is available here: Modern Serverless Development Part 6 – Deploying with Azure DevOps
About the author
Kevin McDonnell is a respected Senior Technical Architect at Ballard Chalmers. With a Master of Engineering (MEng), Engineering Science degree from the University of Oxford he specialises in .NET & Azure development and has a broad understanding of the wider Microsoft stack. He listens to what clients are looking to achieve and helps identify the best platform and solution to deliver on that. Kevin regularly blogs on Digital Workplace topics and is a regular contributor to the monthly #CollabTalk discussions on Twitter.