AD and Azure B2C PoC solution

Implementing a secure authentication used to require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and more. Fortunately, today the advancements of Microsoft Azure provide all these necessary functions which free up your time and allow you to spend more efforts and energy on providing business value to your customer. Businesses or institutions that open up their resources to external users can now easily restrict access using the Azure AD B2C service with minimal effort on the part of the administrators.

To demonstrate the easiest way to do it, we present you with a proof of concept (PoC) Angular 4 web application and back-end services that utilize two types of cloud-based authentication – Azure AD and Azure B2C, based on the following business case:

Web application with responsive design that serves read-only business analysis data to authenticated users. Corporate users manage the consumer users by adding/deleting them. Both parties – service provider and service consumer leverage out-of-the-box cloud-based authentication with minimal configuration and without neglecting security.

What is Azure B2C and how it is different from Azure AD?

Azure Active Directory (in short – Azure AD) is a cloud identity provider service or Identity as a Service (IdaaS) created by Microsoft. Its primary purpose is to provide authentication and authorization for applications in the cloud (SaaS apps).
One of the key applications relying on Azure AD right now is Microsoft’s own Office 365 or Azure itself.

Azure AD’s main purpose is supporting business organizations with extending their identity reach to the cloud and SaaS applications. On top of this, there are many other enhancements and services provided, such as conditional access, identity protection, application publishing, access to pre-configured applications, etc.

Developers can build applications and easily secure them with Azure AD. In this case, an application can be developed for a single organization (single-tenant) or as a general application (multi-tenant) accessible by any company using Azure AD.

In short – Azure AD is meant for businesses to allow their users to access and work with cloud applications.

Azure AD B2C (Business-to-Consumer) is a separate service, different from Azure AD that is built on the same technology, but for different purposes.

The main difference is that it is not to be used by single organization users. Rather than that, it’s created to allow anyone to sign up as a user in a service with their email or social media account, including  Facebook, Google or LinkedIn.

The purpose of Azure AD B2C is to allow organizations to build a cloud identity directory for their customers.

Used technologies:
Angular 4 – used for the front-end web application.
Microsoft .Net Core 2 – used for two back-end APIs.

PoC architecture:

Fig.1 Architecture of the proof of concept

Angular web app – deployed as an app service in Azure
ClientSiteAPI – app service in Azure
ClientSiteAdminAPI – app service in Azure
Application database – Azure Sql Server database

Configuring Azure resources

The configuration process plays an important part and takes a big part of the work to implementing the solution. It ensures that the resources used to deliver services are properly managed and accurate data about them is available when and where it is needed. Let’s take a closer look at the steps to configuring Azure services.
The Azure resources used for the proof of concept are displayed in Fig. 2. The front-end Angular web application and the two APIs are represented by Azure App services. Each of those has one additional deployment slot – dev, which is an Azure Web app resource. The “dev” deployment slots are configured for continous integration from a Bitbucket repository, so that each time changes are committed, the underlying Azure web resource gets redeployed.

The B2C service is also part of the resources, presented by the ClientSiteB2cTenant.

Fig.2. Azure resources used for the proof of concept

Two important menu options in the default Azure Active directory are the “Users” and “Enterprise applications” options.

The Users list is comprised by the Active directory users (Fig.3). Among them is also a dedicated administrator user (“Test User”) that is authenticating against the Azure AD uses the Admin part of the Angular web application and executes operations against the Admin WebAPI. This user was initially created through the Azure portal.

Fig.3. Active Directory users

There are two web applications associated with the Active directory. These are the two APIs – ClientSite Angular application and ClientSiteAdminAPI (Fig.4). The reason is that the Angular front-end, more specifically, its Admin portal, in combination with the Admin API, is authenticating against the Azure AD (via the Test User credentials).

Fig.4. Enterprise applications associated with the Active directory

Clicking on the Properties menu option for an application shows its Properties page. The major point of interest here is the ApplicationId. Later it would be actively used for configuration purposes in the Visual Studio solution.

Fig.5 Properties view for ClientSite Angular enterprise application.

On the other hand, for the ClientSiteAdminAPI enterprise application, when clicking on the Permissions menu option, there is a single delegated permission which allows for signing in and reading profile data (Fig.6).

The ClientSite Angular permissions are comprised of accessing the AdminAPI and the Azure AD for signing purposes and reading user profile data (Fig.7).

Fig.6. Permissions for the ClientSiteAdminAPI

Fig.7. Permissions for the ClientSite Angular application

Following are the two steps needed to create an associated Azure AD B2C service with the Azure AD. Clicking on the “Create a resource” link at the top of the left-hand navigation leads to an entry field where when entering “b2c” would show couple suggestions. The correct one is “Azure Active Directory B2C” – Fig.8

Fig.8. Creating a new Azure Active Directory B2C tenant

Clicking on the autocomplete option displays the initial Create page for the Azure AD B2C (Fig.9).

Fig.9 Initial wizard page for creating an Azure AD B2C resource

The figure below displays the newly added Azure B2C tenant in the list of resources.

Fig.10. The newly added Azure B2C tenant in the resource view

The Azure AD B2C has its own management portal. It could be accessed by switching the currently active directory from the profile navigation at the top right part of the Azure portal (Fig.10). When switched the active directory’s name is changed beneath the username of the currently logged in user (Fig.11).

Fig.10. Switching between Azure AD and Azure AD B2C tenants

Fig.11. When moving to the Azure AD B2C the name of the currently active directory is also updated in the top right corner of the page.

From configuration perspective, the Azure AD B2C is like the regular Azure AD. It has associated applications and users (Fig.12 and Fig.13). In Fig.12 visible are the two associated applications – the Front-end web app (Angular) and the back-end one (API).

Fig.12 Associated applications with the Azure AD B2C directory

Fig.13. Users of the Azure AD B2C

One core configuration element of the Azure AD B2C are the sign-in policies that allow for the users’ sign-in process integration. Among the different policies’ options visible in Fig.14, the “Sign-in policies” option is the important one that has been configured to work with the web resources. It contains one sign-in policy.

Fig.14. Sign-in policies for the Azure AD B2C

As visible in the figure below the sign-in policy’s settings specify for which application the policy applies, when signed-in, what should be the reply url, and if an access token is issued, for what resource and what scopes the token applies for. When all settings are specified, an url is generated that would be used for the front-end Angular web application login process implementation.

Fig.15. Settings of the Sign-in policy

Fig.16 Application Id in the Properties page for the application.

The application instance properties contain the ApplicationId. It is needed for the Azure connectivity configuration in the Visual Studio project.

Fig. 17 The API access settings for the API application instance

Fig. 18 The API access settings for the Web (Front-end) application instance.

Fig.19.

The Web (Front-end) application instance has the permission to access the API instance using impersonation

Fig.20 The Web (Front-end) application instance has permissions to acquire authentication tokens

Visual Studio solution (API)

To illustrate a real-life scenario and demonstrate how Azure B2C and Azure AD can be used by a custom application, let’s take a look at the following Visual Studio solution, consisting of multiple .NET Core projects:
1. API project – this is the Web API project. It uses .Net Core 2 as an underlying framework (authenticates against Azure B2C)
2. API.Admin – another Web API project, dedicated to Admin related authentication and operations (authenticates against Azure AD)
3. BLL project – Contains the business layer for the solution – the connecting point between the API endpoints and the data access layer
4. Core project – contains the data transfer objects (DTOs) that get populated, transferred and consumed by the Front-end
5. DAL – Data access layer – contains the Entity framework (Core) ORM for the solution
6. DB project – a Database project that contains the schema of the database
7. Tests – contains unit tests for testing the business layer

Fig.21 Visual Studio solution for the API (back-end) solution

Visual Studio Code – Angular 4 project

Next, let’s glance at the front-end solution that uses the back-end services, including admin API, and API, mentioned above.

Fig.22 Angular 4 web application project structure in Visual Studio Code

The Angular web app project follows the standard project structure. It consists of components, modules and services. The assets folder contains the style sheet files and image resources.

The environments TypeScripts files contain the configuration settings such as API endpoint, Azure tenants’ configuration, etc.

To sum up

The provided PoC solution aimed to show that Azure AD and B2C is a powerful platform that enables easy management of resources and can be the shortcut to creating complex systems with authentication for internal and external users. Furthermore, if implemented correctly it can help you save on costs. Integrating both the Azure AD and Azure AD B2C in a single solution helps you use the power of AD, while removing limitations in user capacity and ensuring scalability.

Collaborating daily with number of worldwide corporations we have seen that there is no one single technology to work well in all scenarios. So, don’t be skeptical about mixing and matching technologies and rather carefully create a set of authentication mechanisms to best fit your user constituencies.

Choosing the correct authentication method is the first concern for organizations wanting to move their apps to the cloud and is not to be taken lightly.

Whether you need help with identifying the right technology for your project, switching to a new authentication method or migrating your solution, we can support you!