Elasticsearch How to Set Up Single Sign-On Using Active Directory in OpenSearch

By Opster Expert Team - Gustavo

Updated: Sep 20, 2023

| 4 min read

This article is part 3 of 3 part series:

• Single Sign-On Using SAML
• Single sign-On Using Active Directory
• Single sign-On Using OpenID Connect

Quick links

• Introduction
• How to implement Single Sign-On (SSO) using Azure Active Directory as idP:
  1. Go to https://portal.azure.com/ and select Azure Active Directory
  2. Create a new Enterprise Application
  3. Add users to the application
  4. Configure Single sign-on (SSO) and gather SAML metadata
  5. Enable SAML SSO in OpenSearch
  6. Apply settings
• Conclusion

Introduction

Single sign-on has become a web standard, allowing users to log in to multiple applications using a single set of credentials. 

In this article we will use Azure Active Directory as the idP (Identity Provider) to authorize our native users to see certain Opensearch dashboards without having to maintain two different user lists, or manage multiple dedicated Opensearch sets of credentials.

1. User logs in with Azure AD credentials.
2. Depending on the user group, different role mappings with be applied.
3. Each AD group will be mapped to an Opensearch role with specific permissions.
4. Authorized Dashboards are returned to users.

How to implement Single Sign-On (SSO) using Azure Active Directory as idP

1. Go to https://portal.azure.com/ and select Azure Active Directory

2. Create a new Enterprise Application

Select “Create your own application”.

3. Add users to the application

After adding a user you should see them in the list, just like in the screenshot above.

You should now see the application in https://myapplications.microsoft.com/:

4. Configure Single sign-on (SSO) and gather SAML metadata

Go to Single sign-on and select SAML:

Go to Edit Configuration:

Fill in with the following: 

Basic SAML Configuration 

Identifier (Entity ID) opster-ad-sso
Reply URL (Assertion Consumer Service URL) https://<dashboards_url>/_opendistro/_security/saml/acs
Sign on URL https://<dashboards_url>/_dashboards
Relay State (Optional) Empty
Logout URL (Optional) Empty

Important: There is a bug related to acs endpoints in OpenSearch 2.1which was fixed in version 2.3. Version 2.3 still uses legacy _opendistro endpoints, however, future versions will use the new _plugin endpoints.

Follow bug status here.

Add the following for the Opensearch configuration:

5. Enable SAML SSO in OpenSearch

Users will need to modify 2 files:

/usr/share/opensearch/config/opensearch-security/config.yml

_meta:
 type: "config"
 config_version: 2


config:
 dynamic:
   authc:
     saml_auth_domain:
       http_enabled: true
       transport_enabled: false
       order: 1
       http_authenticator:
         type: saml
         challenge: true
         config:
           idp:
             metadata_url: https://login.microsoftonline.com/eaa74c20-f5cd-46af-8bf0-f051033d302a/federationmetadata/2007-06/<id_gathered_from_azure>
 #SAML's metadata url, provided by your IdP
             Entity_id: https://sts.windows.net/<your_app_id>/
 #SAML's IdP entity ID, provided by your IdP
           sp:
             entity_id: opster-ad-sso
           kibana_url: <your_dashboards_url>/
           roles_key: Roles
           exchange_key: "<HMAC256 generated string>"
       authentication_backend:
         type: noop
     basic_internal_auth_domain:
       description: "Authenticate via HTTP Basic against internal users database"
       http_enabled: true
       transport_enabled: true
       order: 0
       http_authenticator:
         type: basic
         challenge: false
       authentication_backend:
         type: intern

From here, users can use what they’ve gathered so far.

SAML, unlike other protocols, is not meant to be used during user credential exchanges with each request. The security plugin trades the SAML response for a lightweight JSON web token that stores validated user attributes. This token (exchange_key) is signed by an exchange key that users can choose freely. Please note that when this key is changed, all tokens signed with it become invalid immediately. These must also be an HMAC256 string and 32 characters max.

To generate one users can go to Free HMAC-SHA256 Online Generator Tool | Devglan and assign it to the exchange_key. 

It is important to also have basic auth enabled because SAML only works for dashboards, authentication for OpenSearch API calls are still needed.

/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml

For Dashboards to be able to use SAML SSO, users must add the following to theiropensearch_dashboards.yml file

​​opensearch_security.auth.type: "saml"
server.xsrf.allowlist: ["/_plugins/_security/saml/acs/idpinitiated", "/_plugins/_security/saml/acs", "/_plugins/_security/saml/logout", "/_opendistro/_security/saml/acs"]

This will enable SAML and whitelist the SAML endpoints.

6. Apply settings

To apply settings users must: 

a) Apply changes with securityadmin.sh – OpenSearch documentation

Example: 

Cd to the /usr/share/opensearch/plugins/opensearch-security/tools directory and run: 

./securityadmin.sh -cd ../../../config/opensearch-security/ -icl -nhnv   -cacert ../../../config/root-ca.pem   -cert ../../../config/kirk.pem   -key ../../../config/kirk-key.pem

b) Restart OpenSearch 

Now when users access theOpenSearch Dashboards URL, they will see the Azure AD Login page.

After login, users should see their username, and no roles assigned under “roles and identities.”

Copy the username.

Now add roles to this particular user via roles mapping API. In this example we will grant our recently created user the “all_access” role mapping.

curl -k --location --request PUT 'https://admin:admin@localhost:9200/_plugins/_security/api/rolesmapping/all_access' \
--header 'Content-Type: application/json' \
--data-raw '{
  "backend_roles" : ["admin"],
  "users" : ["user_name_you_copied"]
}'

Upon checking again, you should see that the user has roles assigned: 

Conclusion

Setting up SSO in OpenSearch allows the user to have the same users and permissions across applications hassle-free. Once users  define their AD Groups, they can map these Groups into existent OpenSearch roles.