Introduction

Currently, most applications are federating the authentication to the identity providers in order not to handle any username and passwords. In these cases, each application would have custom code, to select which identity provider, the type of claims being received, etc. This involves a lot of effort if any changes occur in the claims provided by the identity provider. If all these changes are done in a central place, it will minimize the changes in the applications. In this regard, an identity aggregator would be required which would handle the type of identity providers and the claims mapping. As an identity aggregator, the Azure AD B2C was chosen.

The Micro Services architecture was chosen as the best practice architecture which we need to conform to. Such architecture entails that the application which is divided into small re-usable parts/services, need to be aware of who is the user going to consume such services. Furthermore, Azure AD B2C by using OAuth protocol and JWT tokens, will help us in achieving this.

In order to have a standardized approach, it was decided that during the authentication, we would also check the authorisation of the user. On the other hand, each line of business, has its custom authorisation setup and methodology. By using Azure AD B2C, this can be achieved by calling a line of business API within the User Authentication Journey. Based on the user who was authenticated the roles or specific attributes will be retrieved where the application would determine if the user is authorised or not.

In some business cases, there is the need that users, which are not Maltese citizens, need to make use of government services. In such cases, we need to have a way where users can register and be verified. Our intention is to make use of the Sign-Up functionality within Azure Ad B2C to register the users, and then make use of a KYC product to verify further the user being registered.

Scope

The scope of this document is to cover the authentication flow of Azure AD B2C and the integration with the line of business applications.

High-Level Diagram

As depicted in the below diagram, each line of business will have the web applications implemented on the line of business resource group in conjunction with the APIs especially with the Authority API. This application will be then connected with the Azure Ad B2C using the OpenID Protocol. A description depicting all the flow in more detail.

Steps:

1. User goes to web application and select the Sign In functionality.
2. Web app will redirect the user to the Azure AD B2C to the specified Relying Part.
3. Azure Ad B2C starts the User Journey defined in the Relying Party
4. The user is then redirected to the Identity Provider Authentication page.
5. The user authenticates with the federated Identity Provider.
6. The identity provider sends the claims to the user.
7. The user browser is redirected to the Azure AD B2C to continue the User Journey.
8. Azure AD B2C as specified in the User Journey calls the Authority API on the API manager.
9. The API Manager will call the back-end Authority API, where based on the logged in user, will determine the extra line of business attributes
10. The back-end pass the response to the API manager.
11. The API manager send the attributes to the Azure AD B2C which adds the extra attributes to the claim set.
12. The claims are sent to the user browser.
13. The user’s browser redirect to the line of business web application with the claims received from Azure AD B2C.
14. The line of business web application will process the claims and according to the claims, will determine which functionality the user have access to.

Protocols

Azure Ad B2C supports the below authentication protocols:

1. Security Assertion Markup Language (SAML 2.0)
2. WS-Federation
3. OpenId Connect

All these protocols, federate the authentication to the appropriate Identity Provider and provide Single Sign On. For SAML and WS-Federation, both use the Metadata for discovery and certificates for the trusting (Encryption and Decryption) between the service provider and the application.  On the other hand, OpenId Connect is a protocol built on OAuth where by the use of JSON Web Tokens (JWT) provides a mechanism of Single Sign On authentication and resource authorisation.

OpenId Connect is the recommended protocol, and OAuth is required when Web APIs will be secured, i.e. it requires a valid JWT (Access Token) to be able to consume the API.

Client Applications & Authentication Flow

Azure AD B2C can be used with the different types of application. Below is the list of application types with the appropriate Authorisation flow:

Libraries

Regarding the libraries to be used for the applications to connect to Azure AD B2C, it is suggested that ideally a Microsoft supported library is used. There exist two main libraries which are Azure Active Directory Authentication Library (ADAL) and Microsoft Authentication Library (MSAL).  The preferred library is MSAL.

The below URL shows the Microsoft supported libraries for Client based applications and Server applications.

https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-v2-libraries

Claim Sets

Depending on which Identity Provider you need to federate the authenticate, a predefined set of claims can be retrieved. Two types of claim set exist, namely a Basic claim set which contains minimal user information or the extended claims set which contains all the claims from the identity provider. Based on the nature of the business requirement, the claim set need to be determined. Below are the different claim sets for each identity provider.

On-Boarding

The below details are required to create the configuration for the application on Azure AD B2C:

After the configuration, you would be provided with the below attributes required to connect to Azure Ad B2C:

Client Id/ Application Id

Client Secret

Scopes

B2C Onboarding Form