Enabling secure access to Kibana using Elascticsearch SAML Auth and AWS SSO

Amazon Elasticsearch Service now natively supports using Security Assertion Markup Language (SAML) to offer single sign-on (SSO) for Kibana. SAML authentication for Kibana enables users to integrate directly with third-party identity providers (IDP) such as Okta, Auth0, etc.

In this article, I’ll show you how to secure access to Kibana through AWS Single Sign-On (AWS SSO) and Elasticsearch’s fine-grained access control so that only users authenticated to AWS SSO can access data stored in Amazon ES. I’ll also show you how to map users between an Amazon ES domain and a specific AWS SSO group to manage the permissions authenticated users have to a given Amazon ES domain.


  1. From the AWS Management Console, go to Elasticsearch Service.
  2. Choose the domain, Actions, and Modify authentication.
  3. Check Enable SAML authentication.
  4. Note the service provider entity ID and the two SSO URLs. You only need one of the SSO URLs (Figure 1).

The Kibana login flow can take one of two forms:

  • Service provider (SP) initiated: You navigate to Kibana (for example, https://my-domain.us-east-1.es.amazonaws.com/_plugin/kibana), which redirects you to the login screen. After you log in, the identity provider redirects you to Kibana.
  • Identity provider (IdP) initiated: You navigate to your identity provider, log in, and choose Kibana from an application directory.

We will be using the Identity provider (IdP) initiated flow.

Leave this tab open on your Elasticsearch domain. Open another browser tab and navigate to AWS SSO.

Figure 1: Elasticsearch domain with SAML authentication enabled

Use a SAML tracer tool to inspect the SAML assertion to debug any authentication issues that might arise.

  1. From the AWS Management Console, go to AWS Single Sign-On.
  2. select Applications and then Add a new application. Select Add a custom SAML 2.0 application.
  3. Enter a name for your application (for example, “Kibana”) and scroll down to Application metadata. Select the link that reads If you don’t have a metadata file, you can manually type your metadata value (Figure 2).
  4. Enter the following values for the Application metadata:

a. Application ACS URL: the IdP-initiated SSO URL from your Elasticsearch domain

b. Application SAML audience: the Service provider entity ID from your Elasticsearch domain

5. Click Save changes.

Figure 2: Application metadata

Add attribute mappings

AWS SSO allows you to define a set of user attributes under the Attribute mappings tab found on your application’s configuration page. AWS SSO uses these user attributes to populate SAML assertions (as SAML attributes) that are sent to the cloud application. Each cloud application determines the list of SAML attributes it needs for successful single sign-on. AWS Elasticsearch service requires Subject, User, and Groups.

  1. Switch to the Attribute mappings tab
  2. Next to Subject, enter ${user:subject} and select unspecified under Format as shown in the screenshot below (Figure 3).
  3. Click Add new attribute mapping
  4. Enter User as the User attribute in the application, next to User enter ${user:user}, select unspecified under Format
  5. Do the same for the Groups attribute and map it to ${user:groups}
  6. Click Save Changes.
Figure 3: Adding Attribute Mappings

Assign users

To manage who has access to Kibana we will need to assign users to the application

  1. Switch to the Assigned users tab and select Assign users.
  2. Add individual users or groups.
Figure 4: Adding users to the SAML application

Download SAML metadata

Next, you’ll need to download the AWS SSO SAML metadata. The SAML metadata contains information such as SSO entity ID, public certificate and single sign-on endpoints.

  1. To download the metadata .xml file, switch to the Configuration tab and select Download metadata file (Figure 5).
Figure 5: download SAML metadata file
  1. Head back to the tab with your Elasticsearch domain. Still, under Modify Authentication, go to the Import IdP metadata section.
  2. Copy and paste the contents of the IdP metadata file into the Metadata from IDP field in the AWS console. Alternately, upload the metadata file using the Import from XML file button.
  3. Check that the IDP entity ID field auto-populated from uploading the metadata file. If it has not, copy and paste the contents of the entityID property from your metadata file into the IDP entity ID field in the AWS console.
  1. Provide a SAML master username and/or a SAML master backend role. This username and/or backend role receives full permissions to the cluster, equivalent to a new master user, but can only use those permissions within Kibana.

In AWS SSO, for example, you have a user jdoe who belongs to the group admins. If you add jdoe to the SAML master username field, only that user receives full permissions. If you add admins (group id) to the SAML master backend role field, any user who belongs to the admins group receives full permissions.

2. Expand the Optional SAML settings section (Figure 6).

3. Leave the Subject key field empty to use the NameID element of the SAML assertion for the username.

4. To use backend roles, enter Groups for the Role key field, the attribute mapping you had added to the SSO application.

Figure 6: Optional SAML settings

5. By default, Kibana logs users out after 60 minutes. You can increase this value up to 1,440 (24 hours) using the Session time to live field.

6. Choose Submit. The domain will enter a processing state.

7. After the domain finishes processing, open Kibana.

  • navigate to your AWS SSO page and select the Kibana application.

To allow other users no to access Kibana we need to map the SAML provider (AWS SSO) roles to the roles defined in Kibana.

  1. After Kibana loads, choose Security and Role Mappings.
  2. Map your AWS SSO groups (back-end role) to the desired Kibana roles. Make sure to use the AWS SSO Group ID attribute.
  3. Click Submit

I’ve outlined an approach to securing access to Kibana, through fine-grained access control and integrating AWS SSO. This approach reduces the overhead of integrating Amazon Cognito and offers additional ways of controlling access to your data on Amazon Elasticsearch Service.

Reference articles

Data Engineer