Using Azure Active Directory as an Identity Provider in Keycloak

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service.

Keycloak is an identity and access management solution under the wing of Red Hat. Keycloak allows users of an application to sign in with multiple different Identity Providers and keep users in multiple User Federations. In this article we will go through the process of setting up Azure Active Directory as an Identity Provider in Keycloak.

Prerequisites

All you will need is

# an Azure Active Directory organisation with users to test and,

# a Keycloak instance with admin user and credentials

Adding the Identity Provider

After logging in as an Admin user and selecting your realm, click on ‘identity providers’ in the left-hand tree-view. In the ‘Add provider’ drop-down-menu select ‘openID Connect v1.0’ under user-defined.

As the alias, choose a name you prefer. Copy the Redirect Uri,since we would want to use it later on the azure active directory side. Leave the others to their defaults as shown below.

Now, in the Azure Active Directory, In your respective organization, navigate to App Registrations view by clicking ‘App registrations’ in the left-hand tree view. In the App Registrations view, click on ‘New Registration’ button on the upper left corner.

In the ‘Register an application’ view, choose a name you prefer as name. I have kept Supported account types as default. Now paste the Redirect URI we copied earlier as the Redirect URI. Click ‘Register’ to register the application.

After registering the application, you can see details of the application under ‘essentials’. Copy the Application(client) ID as we will need it later. On top of essentials view, click on ‘Endpoints’ button to view endpoints.

Although there are many endpoints, We only need the two mandatory ones for now. Copy and paste the ‘OAuth 2.0 authorization endpoint(v2)’ and ‘OAuth 2.0 token endpoint(v2)’ in their respective fields in Keycloak under ‘OpenID Connect Config’ in ‘Add identity provider’ view.

would look similar to this in the Keycloak ‘OpenID Connect Config’ in ‘Add identity provider’ view.

Now in the application left side tree view, Click ‘certificates and secrets’ to navigate to certificates and secrets view. Under ‘Client secrets’, click ‘New client secret’ to open ‘Add a client secret’ view.

Add a description, select a time period to expire and add click ‘Add a client secret’.

To get the client secret, under ‘Client secrets’, copy the value.

Under client Authentication in Keycloak add identity provider window, Select ‘Client secret sent as post’. Then use the client ID and the value of the client secret we copied earlier in the ‘Add identity provider’ view in Keycloak.

And we can also set our default scopes to ‘openid profile email’ to get those details from azure active directory to Keycloak.

Now we can see that we have completed filling all the mandatory fields with red asterisks. Now keep the others as default and hit save.

Testing the Identity Provider

In order to test the Azure Active Directory as our Identity Provider, now we will use a test user in our Azure Active Directory to login to Keycloak.

First, navigate to ‘Clients’ tab and open the base URL of account-console client.

As seen in the picture below, We can see that, now, an alternative sign in method is also available in the sign in prompt window.

When we click the alternative sign in button(with the name you have chosen earlier, we are redirected to a Microsoft sign in page.

If we provide a valid user and his credentials, we can login successfully.

I used ‘testuser@carpeorg.onmicrosoft.com’ as my email and after providing credentials signing in was successful.

After a successful login, click on ‘Signing In’ link under Account Security.

We can see that the password is not set for the user.

This is because the user’s password is provided by another identity provider(In our case, Azure Active Directory). Since the user itself was not created in Keycloak, we can confirm that our Azure Active Directory connection as an identity provider is working as expected.