Our Blog

Kibana Single Sign-On with OpenId Connect and Azure Active Directory


Open distro supports OpenID so you can seamlessly connect your Elasticsearch cluster with Identity Providers like Azure AD, Keycloak, Auth0, or Okta. To set up OpenID support, you just need to point Open distro to the metadata endpoint of your provider, and all relevant configuration information is imported automatically. In this article, we will implement a complete OpenID Connect setup including Open distro for Kibana Single Sign-On.

What is OpenID Connect?

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, the discovery of OpenID Providers, and session management, when it makes sense for them.

Configuring OpenID Connect in Azure AD

Next, we will set up an OpenID Connect client application in Azure AD which we will later use for Open Distro for Elasticsearch Kibana Single Sign-On. In this post, we will just describe the basic steps.

Adding an OpenID Connect client application

Our first step is, we need to register an application with the Microsoft identity platform that supports OpenID Connect. Please refer to the official documentation.

Login to azure ad and open the Authentication tab in-app registrations and enter the redirect URL as https://localhost:5601/auth/openid/login and save it.

redirect URL – https://localhost:5601/auth/openid/login

Besides the client ID, we also need the client secret in our Open Distro for elasticsearch Kibana configuration. This is an extra layer of security. An application can only obtain an id token from the IdP if it provides the client secret. In Azure AD you can find it under the Certificates & secrets tab of the client settings.

Connecting OpenDistro with Azure AD

For connecting Open Distro with Azure AD we need to set up a new authentication domain with type openid in config.yml. The most important information we need to provide is the Metadata Endpoint of the newly created OpenID connect client. This endpoint provides all configuration settings that Open Distro needs. The URL of this endpoint varies from IdP to IdP. In Azure AD the format is:

openId end point IDP – https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/v2.0/.well-known/openid-configuration

Since we want to connect Open Distro for Elasticsearch Kibana with Azure AD, we also add a second authentication domain which will use the internal user database. This is required for authenticating the internal Kibana server user. Our config.yml file now looks like:



              http_enabled: true 

              transport_enabled: true 

              order: 0 


                 type: “basic” 

                 challenge: false 


                 type: “internal” 


              enabled: true 

              order: 1 


                 type: openid 

                 challenge: false 


                     subject_key: preferred_username 

                     roles_key: roles 

                     openid_connect_url: https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-



                   type: noop

Adding users and roles to Azure AD

While an IDP can be used as a federation service to pull in user information from different sources such as LDAP, in this example we use the built-in user management. We have two choices when mapping the Azure AD users to Open Distro roles. We can do it by username, or by the roles in Azure AD. While mapping users by name is a bit easier to set up, we will use the Azure AD roles here.

With the default configuration, two appRoles are created, skedler_role and guidanz_role, which can be viewed by choosing the App registrations menu item within the Azure Active Directory blade, selecting the Enterprise application in question, and clicking the Manifest button

A manifest is a JSON object that looks similar to:

“appId”: “xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx”,

“appRoles”: [


   “allowedMemberTypes”: [



   “description”: “Skedler with administrator access”,

   “displayName”: “skedler_role”,

   “id”: “xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx”,

   “isEnabled”: true,

   “value”: “skedlerrole”



   “allowedMemberTypes”: [



   “description”: “guidanz with readonly access”,

   “displayName”: “guidanz_role”,

   “id”: “xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx”,

   “isEnabled”: true,   

   “value”: “guidanzrole”


         ], … etc.  


There are many different ways we might decide to map how users within AAD will be assigned roles within Elasticsearch, for example, using the tenantid claim to map users in different directories to different roles, using the domain part of the name claim, etc.

With the role OpenID connect token attribute created earlier, however, the appRole to which an AAD user is assigned will be sent as the value of the Role Claim within the OpenID connect token, allowing:

  • Arbitrary appRoles to be defined within the manifest
  • Assigning users within the Enterprise application to these roles
  • Using the Role Claim sent within the SAML token to determine access within Elasticsearch.

For the purposes of this post, let’s define a Superuser role within the appRoles:


  “appId”: “<guid>”,

  “appRoles”: [


      “allowedMemberTypes”: [



      “displayName”: “Superuser”,

      “id”: “18d14569-c3bd-439b-9a66-3a2aee01d14d”,

      “isEnabled”: true,

      “description”: “Superuser with administrator access”,

      “value”: “superuser”


    … other roles


  … etc.

And save the changes to the manifest:

Configuring OpenID Connect in Open Distro for Kibana

The last part is to configure OpenID Connect in Open Distro for Kibana. Configuring the Kibana plugin is straight-forward: Choose OpenID as the authentication type, and provide the Azure AD metadata URL, the client name, and the client secret. Please refer to the official documentation.

Activate OpenID Connect by adding the following to kibana.yml:

opendistro_security.auth.type: “openid”

opendistro_security.openid.connect_url: “https://login.microsoftonline.com/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/v2.0/.well-known/openid-configuration”

opendistro_security.openid.client_id: “xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx” 

opendistro_security.openid.client_secret: “xxxxxxxxxxxxxxxxxxxxxxxxxxx”

opendistro_security.openid.base_redirect_url: “https://localhost:5601”

Done. We can now start Open Distro for Kibana and enjoy Single Sign-On with Azure AD! If we open Kibana, we get redirected to the login page of Azure AD. After providing username and password, Kibana opens, and we’re logged in.


OpenID Connect is an industry-standard for providing authentication information. Open Distro for Elasticsearch and their Open Distro for Kibana plugin support OpenID Connect out of the box, so you can use any OpenID compliant identity provider to implement Single Sign-On in Kibana. These IdPs include Azure AD, Keycloak, Okta, Auth0, Connect2ID, or Salesforce.


If you wish to have an automated reporting application, we recommend downloading  Skedler Reports.

Automate your Grafana Grafana and  Kibana Reports Today!
Reporting Made Simple.

Start your free trial

Start your 15-day free trial with instant download

Automate what’s slowing you down. Focus on what fires you up.

Copyright © 2024 Guidanz Inc
Translate »