Building SAML Federation for OpenSearch Serverless with Azure Active Directory

Successfully integrating disparate technologies to create efficient and secure systems is essential, especially as IT infrastructure becomes more complex. For example, organisations that store vast amounts of data, need access to advanced search and analytical capabilities, and we will walk you through how to achieve that capability. This article provides a detailed walkthrough to configuring federated Single Sign-On (SSO) access between OpenSearch Serverless Dashboard and Azure Active Directory (now Microsoft Entra ID) either through Service Provider (SP) or Identity Provider (IdP) initiated access.

Before we dive into the tutorial, let’s familiarise ourselves with the platforms and tools that will feature in this guide:

Azure Active Directory

Azure Active Directory (now Microsoft Entra ID) is a cloud-based identity and access management service developed by Microsoft and serves as a gatekeeper in this particular set-up. The platform manages user permissions, ensuring only authorised personnel can access OpenSearch resources.

OpenSearch Serverless

Amazon’s OpenSearch Serverless allows developers to run large workloads without needing to configure, manage or scale OpenSearch clusters. Serverless provides rapid response times, similar to the OpenSearch service, but within a serverless environment that reduces infrastructure management overheads. OpenSearch is based on Elasticsearch and Kibana version 7.10.2, originating as a fork from these versions but keeping their features and functionalities.

SAML Federation

At the core of this integration is SAML Federation, an open standard used by many identity providers. SAML Federation acts as a bridge, allowing for secure communication of user identities between separate domains. 


Prerequisites

Now that we have established a clear understanding of the platforms involved let’s outline the prerequisites to effectively implementing this integration.

To complete this tutorial, you will need the following:

  • An AWS account that is authorised for all OpenSearch Serverless Actions.

  • An Azure-AD account that is authorised to manage Azure enterprise applications.

  • OpenSearch Serverless collection running in AWS.

 Instructions

Register OpenSearch application in Azure-AD

    • Log in to the Azure portal of the account where you want to create the OpenSearch Application.

    • Below Azure Services, open Microsoft Entra ID ( nee Azure Active Directory), on the left of the screen, click on Enterprise applications and select New Application.

    • choose Non-gallery application. 

    • Enter a name of choice as the application name.

    • Click Create to register the application.

      Assign users or groups to the new application.

      Note access finetuning will be carried out on AWS OpenSearch.

    • Under Manage, Select Users and groups.

    • Click Add user/group.

    • Search and select users or groups if they already exist.

    • Click Select

    • Click Assign

    • Follow the steps here if you want to create a new group or user

    • Once the group is assigned under manage, select Users and groups.

    • Select the group, copy the object ID for use in step later. 

      Configure SSO in Azure AD

    • While the new application created above is open, on the left under Manage, choose Single sign-on.

    • Select SAML as the sign-on method.

    • Select Edit to configure.

    • Set Basic SAML Configuration

      • Click Edit, entering the following values:

      • Identifier (Entity ID) enter aws:opensearch:<aws_account_id>

      • Reply URL, enter https://collection.<aws_region>.aoss.amazonaws.com/_saml/acs (this is the ACS URL supplied by aws for saml integration)

      • For SP-initiated saml access leave Sign on URL, empty

      • For IdP initiated saml access for Sign on URL enter <opensearch_enpoint_url>/_dashboards

      • Leave Replay State empty.

      • Leave Logour Url empty.

      • Click Save.

      • You will notice that the Attribute and claim section is editable and SAML signing certificate is now available for download for later use.

  • Set User Attributes & claims.

    • Click Edit

    • The default claim setup is okay you are only enabling access for users.

    • If access is assigned to a group, you need to add an extra claim. Instructions below: 

      • Click Add a group claim.

        • Select Groups assigned to the application.

        • For Source Attribute, Select Group ID.

        • Click Save

Configure OpenSearch Serverless SAML authentication

    • Log into AWS account where OpenSearch Collection is deployed.

    • Go to the OpenSearch Console

    • Under Serverless and Security, Click SAML authentication.

    • select Create SAML provider.

    • provide a Name.

    • Import the metadata downloaded from step 3.

    • Update Additional settings.

      • If a group is assigned in Azure AD, 

        • for Group attribute, enter http://schemas.microsoft.com.ws/2008/06/identity/claims/groups

Create a data access policy 

    • In the OpenSearch service console, under Serverless, Security Select Data access policies 

    • Click on Create access policy

    • Select Add principals,

    • Choose SAML users and groups.

    • Select the SAML provider name for the collection

    • for SAML users and groups, enter group/<object_id of the group in Azure AD>

    • Click Save.

    • Define fine-grain access with Grant, using it to define permissions to the collection and indexes.

    • Click Save.

You can test access to the dashboard by adding yourself as a member of an AD group with permission. 


In Summary: Building SAML Federation for OpenSearch Serverless with Azure Active Directory

Managing complex IT infrastructure requires the methodical integration of several platforms and tools. This tutorial has walked you through the steps to building SAML Federation for OpenSearch Serverless with Azure Active Directory—by using these platforms together, organisations can access vast data resources easily and enhance security protocols.