SAML with Other IdPs

This guide covers how to set up SAML federation with identity providers other than Okta — including Microsoft Entra ID (Azure AD), Ping Identity, OneLogin, and any SAML 2.0-compliant IdP. The core concepts are the same regardless of your IdP; only the IdP-side configuration steps differ.

OpenSearch UI doesn't support direct SAML integration the way OpenSearch Dashboards does. Instead, SAML federation goes through one of two AWS intermediaries:

Recommendation: Use the IDC path whenever possible. It provides a better SSO experience, supports SCIM user provisioning, and enables per-user access control.

This path uses your IdP as an external identity source for IAM Identity Center. IDC handles the OpenSearch UI integration.

These steps apply to any SAML IdP. The IdP-specific configuration is noted where it differs.

1. Open the IAM Identity Center console 
2. Go to Settings → Identity source → Actions → Change identity source
3. Choose External identity provider
4. Download the IDC SAML metadata (you'll upload this to your IdP)
5. Note the ACS URL and Entity ID from the metadata — you'll need these in your IdP

Create a new SAML 2.0 application in your IdP with these settings:

1. Download the SAML metadata XML from your IdP
2. In the IDC console, upload the metadata file to complete the identity source change

SCIM automatically syncs users and groups from your IdP to IDC:

1. In IDC Settings → Provisioning, enable automatic provisioning
2. Copy the SCIM endpoint URL and access token
3. Configure SCIM in your IdP using the endpoint and token

Follow the IDC Auth Setup guide starting from Step B (creating the IAM role).

1. In IDC, go to Applications → your OpenSearch UI application
2. Assign the synced users or groups

1. In the Azure portal , go to Microsoft Entra ID → Enterprise applications → New application
2. Choose Create your own application
3. Select Integrate any other application you don't find in the gallery (Non-gallery)
4. Name it (e.g., "OpenSearch UI SSO") and choose Create
5. Go to Single sign-on → SAML
6. In Basic SAML Configuration:
   • Identifier (Entity ID): Paste the Entity ID from IDC metadata
   • Reply URL (ACS URL): Paste the ACS URL from IDC metadata
7. Download the Federation Metadata XML — upload this to IDC

1. In the enterprise application, go to Provisioning → Get started
2. Set Provisioning Mode to Automatic
3. Under Admin Credentials:
   • Tenant URL: Paste the SCIM endpoint from IDC
   • Secret Token: Paste the SCIM access token from IDC
4. Choose Test Connection to verify, then Save
5. Under Mappings, configure attribute mappings for users and groups
6. Set Provisioning Status to On

1. In the PingOne admin console , go to Connections → Applications → Add Application
2. Choose SAML Application
3. Enter a name (e.g., "OpenSearch UI SSO")
4. Under SAML Configuration, choose Import Metadata and upload the IDC metadata file
5. Alternatively, manually configure:
   • ACS URL: From IDC metadata
   • Entity ID: From IDC metadata
   • Name ID Format: EmailAddress
6. Save and download the PingOne metadata XML — upload this to IDC

1. In the application settings, go to Provisioning
2. Enable outbound provisioning
3. Configure the SCIM connection:
   • SCIM URL: Paste the SCIM endpoint from IDC
   • Authentication: Bearer token — paste the SCIM access token
4. Map user attributes and enable provisioning

1. In the OneLogin admin portal , go to Applications → Add App
2. Search for "SAML Custom Connector (Advanced)" and select it
3. Name it (e.g., "OpenSearch UI SSO") and Save
4. Go to the Configuration tab:
   • ACS (Consumer) URL: From IDC metadata
   • Audience (Entity ID): From IDC metadata
   • SAML nameID format: Email
5. Go to the SSO tab and download the Issuer URL metadata — upload this to IDC

1. In the application, go to Provisioning
2. Enable provisioning
3. Configure the SCIM connection with the IDC endpoint and token
4. Map attributes and save

Use this path if you can't enable IAM Identity Center. Your IdP federates directly into an IAM role via AWS STS.

Configure a SAML 2.0 application with these AWS-specific settings:

Add these attribute statements in your IdP's SAML configuration:

Example Role attribute value:

Download the metadata XML from your IdP, then create the provider:

Users access OpenSearch UI through the AWS federated console:

1. User clicks the app tile in the IdP portal
2. IdP sends a SAML assertion to AWS
3. User lands in the AWS Console with the federated role
4. User navigates to OpenSearch Service → OpenSearch UI → their application

You can implement per-group access control by mapping IdP groups to different IAM roles. This works with both Path 1 (IDC) and Path 2 (SAML IAM federation).

Create separate IAM roles with different permissions for different groups:

In your IdP, configure the SAML Role attribute to map each group to its corresponding IAM role.

For more granular control at the index level, configure SAML-based fine-grained access control on your OpenSearch domains:

1. In your IdP, add custom SAML attributes:

   • A subject key attribute (e.g., UserName → user's email) for authentication
   • A roles key attribute (e.g., groups → user's group memberships) for authorization

2. On the OpenSearch domain, enable IAM Federation and configure the subject key and roles key:

1. Map IdP groups to OpenSearch security roles using backend roles mapping.

• SAML with Okta — Dedicated Okta integration guide
• IDC Auth Setup — Full IDC setup walkthrough
• IAM Auth Setup — IAM-only authentication
• IAM Policies Reference — Complete permissions reference
• AWS docs: SAML federation with OpenSearch UI 
• AWS docs: Connect to an external identity provider (IDC)