Microsoft Entra ID integration from ADAL to MSAL

ADAL to MSAL

The latest version of Turbo360 comes with changes in the implementation of Microsoft Entra ID integration for authentication. Previously Turbo360 was using the ADAL authentication library, which is planned to be deprecated, and we needed to migrate to the MSAL library. More info on the library migration is available on this link: https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-migration.

Microsoft Entra ID integration in Turbo360

Turbo360 uses Microsoft Entra ID as an authentication provider for 2 key reasons:

• Authentication: The user is authenticated against Microsoft Entra ID and is granted a token that can be used with Turbo360.
• Authorization: To pull a user or group from the Microsoft Entra ID to be associated with a role in Turbo360.

Two-step migration

Turbo360 customers will either use the SaaS version of Turbo360 or self-host their instance of Turbo360 in their Azure subscription, which is referred to as private hosting or PH.

When a customer has upgraded their PH instance of Turbo360 to the latest version, the authentication library upgrade needs two additional one-off steps:

• Kovai registers the customer’s PH URL on the Kovai App Registration
• Customer provides an API consent for the Turbo360 App Registration on Customer’s Microsoft Entra ID tenant

This article aims to clarify the need for the above-mentioned 2 steps with technical information:

The Login flow

The flow for the login can be viewed as follows:

The below diagram shows the component view of the authentication architecture.

When your user logs into the Turbo360 Portal, the authentication will send you to the Kovai multi-tenant app registration, to verify if the request comes from one of the whiltelisted URLs. You will then be redirected to your tenant to authenticate, and the token will be returned to the application.
In the application, your Turbo360 administrator user is validated using RBAC, and the administrator can choose to add other users and groups from your Microsoft Entra ID tenant to be able to be given access to your PH instance of Turbo360.

What has changed?

Previously when the ADAL library was used, we could dynamically configure the library to authenticate directly against the customer’s Microsoft Entra ID tenant without the hop via the Kovai Microsoft Entra ID instance.

The MSAL library does not out of the box support this dynamic configuration of the tenant/client id, so we would need to produce an individual installation for each customer. The recommended approach is what is typically used for SaaS applications where the application developer has their app registration which is multi-tenant, and will then allow users to federate to their Microsoft Entra ID for authentication using the organization account. This is the way the SaaS hosted version of Turbo360 has always worked and the way most other single-page applications using Microsoft Entra ID for authentication would work when they are developed to support multi-tenant.

The main difference from a customer perspective if you are upgrading from the previous version of Turbo360 is that we will need to register the URL of your PH installation as a redirect URL on the Kovai multi-tenant app registration. This is the list of apps that are allowed to use that app registration for authentication.

Having the application deployed with the configuration for authentication pointing to the Kovai Microsoft Entra ID app registration allows us to have a single deployment package that supports all PH customers. Then when the app has been installed, the act of logging into the application will redirect the user to their home Microsoft Entra ID tenant to log in.

There are 2 one time setup steps that are done when the customer sets up Turbo360 for the first time or migrates to the new version from the version which used ADAL which is:

• Kovai will register the URL of the customer’s PH installation as a redirect URL on the Kovai multi-tenant App Registration
• When the customer admin logs in for the first time, they will do a consent on their home Microsoft Entra ID, which will allow the application to be able to configure users for the RBAC setup in the application. This is the same approach typically taken when setting up an application for Microsoft Entra ID.

Summary

Hopefully, the document will provide some additional technical notes on the ADAL to MSAL migration and explain how the login process works and the additional steps which are involved in the one-time setup.

We will be monitoring the future roadmap for MSAL as other users have requested the feature to dynamically configure the client id at runtime. There is some custom-coded workaround that some developers have implemented, but we feel that at this time, it’s better to stick to the out-of-the-box supported approaches with the multi-tenant application being the way most ISVs will implement this pattern, but when Microsoft support dynamically setting the tenant, then we would look to provide this as an additional option for Turbo360 customers.

Reference

If you want to look into more info about this topic, there are some additional links below:

1. https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant
2. https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/1403
3. https://stackoverflow.com/questions/67772591/dynamic-configuration-of-msal-2-in-angular
4. https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-client-application-configuration
5. https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md