« Secure your clusters with OpenID Connect Secure your clusters with Kerberos »

› › ›

Set up OpenID Connect with Azure, Google, or Okta

This page explains how to implement OIDC, from the OAuth client credentials generation to the realm configuration for Elasticsearch and Kibana, with the following OpenID Connect Providers (OPs):

For further detail about configuring OIDC, check our list of references at the end of this article.

Setting up OpenID Connect with Azure

edit

Follow these steps to configure OpenID Connect single sign-on on Elasticsearch Service with an Azure OP:

Configure the OAuth client ID:
1. Create a new application:
  1. Sign into the Azure Portal and go to Entra (formerly Azure Active Directory). From there, select App registrations > New registration to register a new application.
  2. Enter a Name for your application, for example ec-oauth2.
  3. Select a Supported Account Type according to your preferences.
  4. Set the Redirect URI as KIBANA_ENDPOINT_URL/api/security/oidc/callback. You can retrieve your KIBANA_ENDPOINT_URL by opening the Elasticsearch Service Console and selecting the Kibana Copy endpoint link in your deployment details.
  5. Select Register.
  6. Confirm that your new Application (client) ID appears in the app details.
2. Create a client ID and secret:
  1. From the application that you created, go to Certificates & secrets and create a new secret under Client secrets > New client secret.
  2. Provide a Description, for example Kibana.
  3. Select an expiration for the secret.
  4. Select Add and copy your newly created client secret for later use.
Add your client secret to the Elasticsearch keystore:
1. Follow the steps described in our security settings documentation to Add a secret value to the keystore:
  1. Set the Setting name as xpack.security.authc.realms.oidc.oidc1.rp.client_secret.
    
    For OIDC, the client secret setting name in the keystore should be of the form: xpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.
  2. For Type, select Single string.
  3. Paste your client secret into the Secret field.
  4. Select Save.

Configure Elasticsearch with the OIDC realm:

To learn more about the available endpoints provided by Microsoft Azure, refer to the Endpoints details in the application that you configured.

A screenshot of the Azure Endpoints dialog with fields for Diplay Name

To configure Elasticsearch for OIDC:

Update your Elasticsearch user settings with the following configuration:

xpack:
  security:
    authc:
      realms:
        oidc:
          oidc1:
            order: 2
            rp.client_id: "<Application (client) ID>"
            rp.response_type: "code"
            rp.requested_scopes: ["openid", "email"]
            rp.redirect_uri: "KIBANA_ENDPOINT_URL/api/security/oidc/callback"
            op.issuer: "https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0"
            op.authorization_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/authorize"
            op.token_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/token"
            op.userinfo_endpoint: "https://graph.microsoft.com/oidc/userinfo"
            op.endsession_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/logout"
            rp.post_logout_redirect_uri: "KIBANA_ENDPOINT_URL/logged_out"
            op.jwkset_path: "https://login.microsoftonline.com/<Directory (tenant) ID>/discovery/v2.0/keys"
            claims.principal: email
            claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

Where:

<Application (client) ID> is your Client ID, available in the application details on Azure.
<Directory (tenant) ID> is your Directory ID, available in the application details on Azure.
KIBANA_ENDPOINT_URL is your Kibana endpoint, available from the Elasticsearch Service Console.
YOUR_DOMAIN and TLD in the claim_patterns.principal regular expression are your organization email domain and top level domain.

Remember to add this configuration for each node type in the User settings if you use several node types based on your deployment architecture (Dedicated Master, High IO, and/or High Storage).

Create a role mapping:

The following role mapping for OIDC restricts access to a specific user (firstname.lastname) based on the claim_patterns.principal email address. This prevents other users on the same domain from having access to your deployment. You can remove the rule or adjust it at your convenience.

More details are available in our Configuring role mappings documentation.

POST /_security/role_mapping/oidc_kibana
{
    "enabled": true,
    "roles": [ "superuser" ],
    "rules" : {
      "all" : [
        {
          "field" : {
            "realm.name" : "oidc1"
          }
        },
        {
          "field" : {
            "username" : [
              "<firstname.lastname>"
            ]
          }
        }
      ]
    },
    "metadata": { "version": 1 }
}

If you use an email in the claim_patterns.principal, you won’t need to add the domain in the role_mapping (for example, firstname.lastname@your_domain.tld should be firstname.lastname).

Configure Kibana with the OIDC realm:

The next step is to configure Kibana, in order to initiate the OpenID authentication:
1. Log in to the Elasticsearch Service Console.
2. Update your Kibana user settings with the following configuration:
```
xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1
    description: "Log in with Azure"
  basic.basic1:
    order: 1
```

Setting up OpenID Connect with Google

edit

Follow these steps to configure OpenID Connect single sign-on on Elasticsearch Service with a Google OP:

Configure the OAuth client ID:
1. Create a new project:
  1. Sign in to the Google Cloud and open the New Project page. Create a new project.
2. Create a client ID and secret:
  1. Navigate to the APIs & Services and open the Credentials tab to create your OAuth client ID.
  2. For Application Type choose Web application.
  3. Choose a Name for your OAuth 2 client, for example ec-oauth2.
  4. Add an Authorized redirect URI. The URI should be defined as KIBANA_ENDPOINT_URL/api/security/oidc/callback. You can retrieve your KIBANA_ENDPOINT_URL by opening the Elasticsearch Service Console and selecting the Kibana Copy endpoint link in your deployment details.
  5. Select Create and copy your client ID and your client secret for later use.
Add your client secret to the Elasticsearch keystore:
1. Follow the steps described in our security settings documentation to Add a secret value to the keystore:
  1. Set the Setting name as xpack.security.authc.realms.oidc.oidc1.rp.client_secret.
    
    For OIDC, the client secret setting name in the keystore should be of the form: xpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.
  2. For Type, select Single string.
  3. Paste your client secret into the Secret field.
  4. Select Save.

Configure Elasticsearch with the OIDC realm:

To learn more about the endpoints provided by Google, refer to this OpenID configuration.

To configure Elasticsearch for OIDC:

Update your Elasticsearch user settings with the following configuration:

xpack:
  security:
    authc:
      realms:
        oidc:
          oidc1:
            order: 2
            rp.client_id: "YOUR_CLIENT_ID"
            rp.response_type: "code"
            rp.requested_scopes: ["openid", "email"]
            rp.redirect_uri: "KIBANA_ENDPOINT_URL/api/security/oidc/callback"
            op.issuer: "https://accounts.google.com"
            op.authorization_endpoint: "https://accounts.google.com/o/oauth2/v2/auth"
            op.token_endpoint: "https://oauth2.googleapis.com/token"
            op.userinfo_endpoint: "https://openidconnect.googleapis.com/v1/userinfo"
            op.jwkset_path: "https://www.googleapis.com/oauth2/v3/certs"
            claims.principal: email
            claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

Where:

YOUR_CLIENT_ID is your Client ID.
KIBANA_ENDPOINT_URL is your Kibana endpoint, available from the Elasticsearch Service Console.
YOUR_DOMAIN and TLD in the claim_patterns.principal regular expression are your organization email domain and top level domain.

Remember to add this configuration for each node type in the User settings if you use several node types based on your deployment architecture (Dedicated Master, High IO, and/or High Storage).

Create a role mapping:

More details are available in our Configuring role mappings documentation.

POST /_security/role_mapping/oidc_kibana
{
    "enabled": true,
    "roles": [ "superuser" ],
    "rules" : {
      "all" : [
        {
          "field" : {
            "realm.name" : "oidc1"
          }
        },
        {
          "field" : {
            "username" : [
              "<firstname.lastname>"
            ]
          }
        }
      ]
    },
    "metadata": { "version": 1 }
}

If you use an email in the claim_patterns.principal, you won’t need to add the domain in the role_mapping (for example, firstname.lastname@your_domain.tld should be firstname.lastname).

Configure Kibana with the OIDC realm:

The next step is to configure Kibana, in order to initiate the OpenID authentication:
1. Log in to the Elasticsearch Service Console.
2. Update your Kibana user settings with the following configuration:
```
xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1
    description: "Log in with Google"
  basic.basic1:
    order: 1
```

Setting up OpenID Connect with Okta

edit

Follow these steps to configure OpenID Connect single sign-on on Elasticsearch Service with an Okta OP:

Configure the OAuth client ID:
1. Create a new application:
  1. Go to Applications > Add Application.
  2. For the Platform page settings, select Web then Next.
  3. In the Application settings choose a Name for your application, for example Kibana OIDC.
  4. Set the Base URI to KIBANA_ENDPOINT_URL. You can retrieve your KIBANA_ENDPOINT_URL by opening the Elasticsearch Service Console and selecting the Kibana Copy endpoint link in your deployment details.
  5. Set the Login redirect URI as KIBANA_ENDPOINT_URL/api/security/oidc/callback.
  6. Set the Logout redirect URI as KIBANA_ENDPOINT_URL/logged_out.
  7. Choose Done and copy your client ID and client secret values for later use.
Add your client secret to the Elasticsearch keystore:
1. Follow the steps described in our security settings documentation to Add a secret value to the keystore:
  1. Set the Setting name as xpack.security.authc.realms.oidc.oidc1.rp.client_secret.
    
    For OIDC, the client secret setting name in the keystore should be of the form: xpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.
  2. For Type, select Single string.
  3. Paste your client secret into the Secret field.
  4. Select Save.

Configure Elasticsearch with the OIDC realm:

To learn more about the available endpoints provided by Okta, refer to the following OpenID configuration: https://{yourOktadomain}/.well-known/openid-configuration

To configure Elasticsearch for OIDC:

Update your Elasticsearch user settings with the following configuration:

xpack:
  security:
    authc:
      realms:
        oidc:
          oidc1:
            order: 2
            rp.client_id: "YOUR_CLIENT_ID"
            rp.response_type: "code"
            rp.requested_scopes: ["openid", "email"]
            rp.redirect_uri: "KIBANA_ENDPOINT_URL/api/security/oidc/callback"
            op.issuer: "https://YOUR_OKTA_DOMAIN"
            op.authorization_endpoint: "https://YOUR_OKTA_DOMAIN/oauth2/v1/authorize"
            op.token_endpoint: "https://YOUR_OKTA_DOMAIN/oauth2/v1/token"
            op.userinfo_endpoint: "https://YOUR_OKTA_DOMAIN/oauth2/v1/userinfo"
            op.endsession_endpoint: "https://YOUR_OKTA_DOMAIN/oauth2/v1/logout"
            op.jwkset_path: "https://YOUR_OKTA_DOMAIN/oauth2/v1/keys"
            claims.principal: email
            claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

Where:

YOUR_CLIENT_ID is the Client ID that you set up in the previous steps.
KIBANA_ENDPOINT_URL is your Kibana endpoint, available from the Elasticsearch Service Console.
YOUR_OKTA_DOMAIN is the URL of your Okta domain shown on your Okta dashboard.
YOUR_DOMAIN and TLD in the claim_patterns.principal regular expression are your organization email domain and top level domain.

Remember to add this configuration for each node type in the User settings if you use several node types based on your deployment architecture (Dedicated Master, High IO, and/or High Storage).

Create a role mapping:

More details are available in our Configuring role mappings documentation.

POST /_security/role_mapping/oidc_kibana
{
    "enabled": true,
    "roles": [ "superuser" ],
    "rules" : {
      "all" : [
        {
          "field" : {
            "realm.name" : "oidc1"
          }
        },
        {
          "field" : {
            "username" : [
              "<firstname.lastname>"
            ]
          }
        }
      ]
    },
    "metadata": { "version": 1 }
}

If you use an email in the claim_patterns.principal, you won’t need to add the domain in the role_mapping (for example, firstname.lastname@your_domain.tld should be firstname.lastname).

Configure Kibana with the OIDC realm:

The next step is to configure Kibana, in order to initiate the OpenID authentication:
1. Log in to the Elasticsearch Service Console.
2. Update your Kibana user settings with the following configuration:
```
xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1
    description: "Log in with Okta"
  basic.basic1:
    order: 1
```

Summary and References

edit

This topic covered how to authenticate users in Kibana using OpenID Connect and different providers: Azure, Google, and Okta. If you are looking for other authentication methods, Elasticsearch Service also supports SAML and Kerberos. Please note that OpenID Connect support is only available for Platinum and Enterprise subscriptions. New to Elasticsearch Service? Sign Up for a Trial to try it out.

To learn more about OIDC configuration consult the following references:

« Secure your clusters with OpenID Connect Secure your clusters with Kerberos »

On this page

Setting up OpenID Connect with Azure
Setting up OpenID Connect with Google
Setting up OpenID Connect with Okta
Summary and References

Was this helpful?

Feedback

The Search AI Company

ELK Stack

Elastic Cloud

Generative AI

Search

Security

Observability

By solution

Industries

Customer spotlight

Research

Build

Learn

Connect

Set up OpenID Connect with Azure, Google, or Okta