Entra ID is tightly coupled on the Azure platform to native services and custom-built applications and services. Of course, migrating away from native Azure services essentially means replatforming: replacing those services entirely by comparable services on other cloud providers. For custom-built applications and services the story is somewhat different: you as the developers are able to change those applications and services at will, but the question is: how to go about it?

The functional parts of those applications and services are not at stake: in whatever programming language you developed those, you will be able to replatform them fairly easily. We all use containers nowadays, right? Which can run everywhere, at least that is the promise. It gets a bit tricky when you have an elaborate authorization setup. On Azure, you probably are tied to Entra ID, and you may even have set up all kinds of custom authorizations for your application.

This blog presents a proposal for migrating your applications and services with the focus on moving away from Entra ID and using a more loosely coupled authentication and authorization platform instead. In the text that follows I will be using Keycloak, but you could also replace that with auth0 for example. The approach remains the same. The idea behind the phases in the approach is to shift and divide cloud costs as quickly as possible. Of course you could also choose for a big bang scenario where all applications and services are migrated entirely before switching off your current Azure setup. In general, that would take quite some time and you will be spending double the cloud costs for that whole period because you need to keep the existing structures running while doing development and testing of a complete new setup on another cloud provider.

Caveat emptor: This blog will not explain how to migrate away from Entra ID in an Office 365 context. If you are looking for a solution to that problem, you won't find it here. Office 365 and Entra ID are really married to each other. Getting rid of Entra ID in this context, requires choosing a completely different platform for your office automation applications, in my mind at least. I hear great things about Proton. And if you do not mind not switching to an EU cloud provider, Google Workspace is also an option for office automation.

First, constraining ourselves to the scope of migrating applications and services from Azure and Entra ID, let’s have a look at migrating the authentication services that are required. The steps to migrate user authentication are:

1. Setup Keycloak with Entra ID as secondary IdP by means of a user federation provider
2. Configure an external B2B identity provider (IdP) in Entra ID to enable authentication of users already in Keycloak
3. Have users log into this new setup

The reason behind using a user federation provider instead of simply using Entra ID as secondary IdP, is so we can have users log in and migrate their accounts from Entra ID behind the scenes. This provider will check user accounts and their credentials against Entra ID and as soon as that is done, the user accounts will be based on Keycloak from then on. This saves you from migrating all users in bulk from Entra ID to Keycloak in one go. But if that is not an issue, you could also migrate all users from the start, and leave the user federation provider out of the equation.

Next, let us have a look at preparing applications and services. The assumption here is that we start with the frontends of applications first: we modify those to make use of the token exchange capabilities of Keycloak. This means that users are authenticated against Keycloak and any tokens they need to provide for the backend services, will be exchanged on the fly for Entra ID tokens by the frontend. Those new tokens are then used against the backend services which still rely on Entra ID tokens.

Of course, this also means that the frontends can be migrated to an EU cloud already. They just need to be able to communicate with Entra ID and the backend services. The picture below does not do justice to the amount of work that will be needed to open up the backend services that are still on Azure. The services need to be exposed using Azure Firewall or Azure API Management to do that in a safe manner.

Now, the backend services are in play: they need to be modified to make use of Keycloak services so they are enabled to validate original Keycloak tokens against the Keycloak IdP. That basically looks like this:

Using this setup, developers can introduce the functionality for communicating with Keycloak, one backend at a time. An important step on the Keycloak side, is to correctly introduce the realms, scopes, groups and roles so the tokens are in line with what the backends expect to be contained in the tokens. Of course, if you already had backlog items on re-engineering the authorizations in your backends, this would be a good time to also start working on those. You can introduce Keycloak specifics and fine-tune your authorization while you are at it.

If all backends have been adapted to work with Keycloak natively, it is time to start moving them to the EU clouds too. This should not be that hard as long as the base platform they are based on, is also available on your EU cloud of choice. If your backends are not based on container technology already, this might still be a substantial task: if core Azure platform services are heavily used, you still need to replatform those backends. Think Azure Functions, Logic Apps, Azure Webapps and such.

You will end up with this situation:

I do not advise you to spend time containerizing your backends on Azure already. That would mean investigating the appropriate container technology on Azure first, such as ACI's, ACA's or using k8s managed (AKS) or not, and it would mean investing on knowledge and experience in Azure specifics that you will not need in the end anymore. Just put that effort towards the EU cloud target platform and keep your Azure specific backends running as-is, but with the Keycloak adaptations, because those are here to stay.

A quick reminder, you can read auth0 here too instead of Keycloak. These software packages are more or less equivalent in what was described here. Both have an important advantage: they are completely based on open standards, such as token exchange (RFC8693), OIDC, OAuth.