Connecting AM and Azure with OIDC

First, let’s set up Microsoft Azure. We’ll assume that we already have users configured in Azure, so we’ll skip that part of the setup.

We need to configure AM as an OIDC client. We’ll do this in Azure Portal (portal.azure.com), where we’ll configure an application via the App Registrations service:

Next, we need to create a new app registration:

Let’s give it a name; for example, “ForgeRock AM”, define who can use our application, and configure a redirect URI that would instruct Azure where to redirect a user when the authentication process is finished Ihttps://[amFQDN]/am or for ForgeRock Identity Cloud https://[amFQDN]/login):

Now, we need to copy the application (client) ID:

What’s definitely missing here is a client secret. We can generate it through the Security section on the left menu:

Once generated, copy the Value, as we’ll need it shortly:

So far, our application (AM) has one privilege assigned (scope) for Azure API; this happens by default. We can review that in the API Permissions section. You should determine the privileges you’ll grant on what’s needed on the application side. By default, only User.Read permission should be assigned; that’s sufficient for our use case. If you need to add additional permissions, click the Add a permission button in the wizard:

AM 7.x makes any OIDC based integration deadly simple.

In our case, there are only two steps involved: preparing a social identity provider service, and creating a user journey (via authentication trees). For a better “visual” effect, we’ll use the Admin UI. The same configuration can be performed in a programatic way using REST API.

We need to configure Azure as one of the social identity providers. This is done on a realm level in the Services section:

We need to make sure the service is enabled:

And then configure microsoft in the Secondary Configurations section, populating the details that were returned when we created an application in Azure:

The only thing we need to change for the default config is Client IDClient ID and Client Secret. The rest is already there. We can tweak the look and feel in UI Config Properties:

We can skip that for now. The important thing to mention here is the transformation script, also called Microsoft profile normalization.

The script converts identity data received from a social provider to a “common” object format. The reason for this is various social providers might bring information in various claims/attributes. Abstracting the normalization part gives us huge flexibility when adding custom identity providers and matching attributes, and, we can normalize whatever identity provider brings to a common format. By the way, we can extend the script to suit our needs. Let’s have a look what the scripts do out-of-the-box by going to the Scripts section in AM administrative console:

As you can see, this script has simple logic and requires minimum effort to adjust (if needed).