OpenSearch SSO and identity integration guide

How do we set up OpenSearch SSO without locking out our own admins?

OpenSearch SSO is configured in the OpenSearch Security plugin and in OpenSearch Dashboards, so the cluster and the dashboard trust the same corporate identity. The Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends, and the identity claims or directory groups those backends return are mapped to backend roles, which the plugin then maps to security roles and tenants. A platform team usually starts with a working cluster and Dashboards, and the directory team asks for corporate sign-in. That request looks like a configuration task, but it involves two separate decisions that fail in different ways.

The first decision is authentication, which establishes who the user is. The second is authorization, which determines what that user may do. Authentication can succeed while authorization fails, so a user signs in to Dashboards and sees empty index patterns or permission errors. These symptoms look like access problems, but they usually come from a claim or group name that does not match the mapping, a missing backend role, or a tenant that was never granted. Before go-live, take one test account per directory group, record the exact claim values the identity provider sends, and confirm which security role each one receives. Ask the directory team for group names in writing, because a renamed group changes access without any change inside OpenSearch.

The lockout risk comes from changing the path that administrators use to sign in. If the identity provider metadata, a certificate or a group claim changes, or if the internal users that remain in the Security plugin are removed too early, the people who can repair the configuration may no longer be able to log in. Keep at least one break-glass admin path that does not depend on the new identity provider, and confirm in the Security plugin documentation for your version how the admin certificate and internal users are handled during the change. Test that path before enabling SSO, and record its owner and where its credentials are stored.

Stage the rollout: enable SSO on a non-production cluster, then sign in with a named admin, a standard user and a user from each directory group before switching production. Record the identity provider settings, role mappings and rollback steps in the change record. Ask the identity team to confirm which claims their identity provider emits, how group membership is refreshed, and how they will notify the platform team before they change a certificate or rename a group. Their answers show how much of the effort is one-time setup and how much is ongoing mapping maintenance.

Which Security plugin pieces handle login and access

A successful login and a correct permission set are decided by different pieces of the OpenSearch Security plugin. Knowing which piece makes which decision tells you where to look when a user can sign in but cannot see the data or screens they expect.

Authentication backends

Authentication backends decide whether a user's identity is accepted. This page centers on SAML, OpenID Connect, and LDAP or Active Directory, which are the common choices for enterprise identity providers. Kerberos and JSON Web Token are also supported by the Security plugin, but they are not the focus here. When a login fails or the wrong identity arrives, check the backend configuration first. Confirm exact file names and settings against the version you run.

Authentication and authorization configuration

The Security plugin separates how users authenticate from how they are authorized. Authentication settings define the order of backends and how credentials are read, while authorization settings define how backend roles are pulled from the identity source. A change in one area does not automatically change the other. Confirm the exact configuration file names and setting keys for your release before editing anything in a live cluster.

Internal users and their roles

Internal users are accounts stored inside the Security plugin's own index rather than in your identity provider. They are useful for service accounts, break-glass administration, and for testing role behavior without a directory. Each internal user is assigned one or more roles directly. If an SSO user appears to bypass the intended permissions, confirm that no internal user with the same name exists, since internal definitions can shape what that account is allowed to do.

Roles and role mappings

Roles define what an identity may do: cluster permissions, index permissions, and, where configured, document-level and field-level restrictions. Role mappings connect incoming identities, such as users, groups, or backend roles from the identity provider, to these roles. This is the most common place where a login succeeds but access is wrong. Review the mapping for each group claim or directory group, and confirm that the role grants the index patterns and actions the user needs.

Backend roles

Backend roles are labels that come from the identity source, such as directory groups or token claims, and they are matched against role mappings. They let you grant access by group membership instead of by individual user. Because backend roles are only as accurate as the identity provider, check what values actually arrive for a test user. Group names with different casing, nested groups that are not expanded, or missing claims are frequent causes of unexpected permissions.

Tenants and TLS for node and client traffic

Tenants in OpenSearch Dashboards separate saved objects such as dashboards, visualizations, and index patterns, and they are assigned through roles. TLS covers node-to-node and client traffic, and it protects the identity exchange with the provider and the session data passed to Dashboards. Use this card to check two things: that each role points to the tenant the user should see, and that certificates are trusted by every component in the login path. Confirm the tenant and TLS settings against your version's documentation.

Which identity protocol fits our directory and Dashboards setup

This table compares SAML, OpenID Connect, LDAP or Active Directory, and internal users for OpenSearch and OpenSearch Dashboards, with the operational work each option leaves to your team. Read each row against your existing identity provider and directory, then use the final rows to decide where group mapping happens and how break-glass access is kept. The main takeaway is that the protocol choice matters less than who owns the certificates, bind accounts and group design over the life of the cluster.

Option	When it fits	Operational cost	Mapping and access notes
SAML with a federated enterprise IdP	Your IdP already federates workforce logins and issues signed assertions to other enterprise apps	Signing certificate and metadata exchange to renew, assertion attribute design, and coordination with the IdP team for every change	Group or role attributes in the assertion map to backend roles; confirm attribute names with the IdP owner before build
OpenID Connect with a modern IdP	Your IdP supports web login flows and you want the browser redirect model for Dashboards sign-in	Client secret or key rotation, redirect URI management per environment, and token claim design that must be kept stable	Claims carry groups or roles into OpenSearch; test claim size and group count, since large group lists can cause login problems
LDAP or Active Directory bind	The directory is the source of truth and the cluster can reach domain controllers or LDAP replicas directly	Bind account with least-privilege read access to rotate, network paths through firewalls, and TLS certificate trust for the directory	Group lookups run against the directory, so directory replica availability directly affects whether users can log in
Internal users with a break-glass admin	Always, as a small set of named emergency accounts that work when the IdP or directory is unavailable	Password custody, documented use procedure, and periodic verification that the accounts still work	Keep these accounts out of daily use and log every login; they should not hold standing data access beyond admin tasks
Mapping on the IdP or directory side	Groups are already curated for other systems and mapping logic should stay with identity owners	Changes need an identity team ticket, and cluster-side testing must follow each change	Reduces OpenSearch configuration, but role intent is spread across two teams and harder to audit in one place
Mapping in OpenSearch role mappings	You need one reviewed place that connects identity attributes to security roles and tenants	Role mapping files or API changes must be version controlled and reviewed on each upgrade	Clear audit trail inside the Security plugin; requires agreed naming conventions for external groups
Backend roles from groups	Users belong to stable groups that match access patterns, such as a team or data domain	Group naming and lifecycle must be governed; orphaned groups quietly keep access	Usually easier to review and scale than per-user mapping; confirm group nesting behavior for your directory
Per-user mapping	A small number of named users need unusual access that no group describes	Every joiner, mover and leaver change touches the cluster, which is slow and error prone at scale	Use sparingly and review regularly, since individual exceptions accumulate over time

How to configure OpenSearch SSO step by step

This sequence moves a cluster from internal accounts to single sign-on for OpenSearch Dashboards and the REST API, with a tested break-glass admin held in reserve. Each step closes with a check so problems surface before the next layer depends on them. Exact settings change between releases, so confirm each one in the documentation for your version.

Confirm versions and supported authentication backends
Confirm the target OpenSearch and Dashboards versions, then check which authentication backends the Security plugin supports for that pair. The plugin covers SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication, but supported options and configuration keys can differ by release. The platform owner records the version pair, the identity provider or directory type, and the protocol each team will use. The step closes when that record is signed off and every later step cites the same versions.
Enable TLS for nodes and clients
Enable TLS for node-to-node traffic and for client connections before any login is configured, so credentials and tokens never cross the network in clear text. The platform engineer issues node and Dashboards certificates from the organization's approved certificate authority and applies them to every node. The check is that a client connects over HTTPS and the certificate chain validates from a host outside the cluster. Confirm the certificate settings against the Security plugin documentation for your release.
Create and test the break-glass admin
Create a break-glass internal admin account and test it before changing any external authentication. This account lives in the internal user database, its credential is stored under the organization's privileged credential process, and it is used only when the identity provider or directory is unavailable. The security engineer logs in with it, runs a cluster health request and confirms admin rights. The step closes when the test login succeeds and the credential is recorded in that process.
Register Dashboards or connect the directory
Register OpenSearch Dashboards with the identity provider, or configure the LDAP or Active Directory connection with a least-privilege bind account. For OpenID Connect or SAML, the identity provider administrator creates the application client using the redirect and callback values defined for your release. For LDAP or Active Directory, the bind account receives read access to the user and group search base only. The step closes with a successful test login through the identity provider, or a successful bind and user search from the cluster.
Set backend order and login settings
Set the authentication backend order and the Dashboards login settings, including session lifetime and logout behavior. The Security plugin tries configured backends in sequence, so any fallback to internal users should be deliberate and limited to the break-glass account. The engineer applies the settings and reloads the security configuration as your release requires. The check is that a directory user reaches Dashboards through the intended login path, and an account outside the directory is refused.
Pass groups or claims to backend roles
Send group membership from the identity provider or directory into the cluster as backend roles. The identity provider must include group data in a token claim or SAML attribute, and the cluster must map that value to a backend role. Ask the identity provider administrator for a sample token or assertion for a test user, then review the security logs or audit output to see which backend roles are assigned at login. The step closes when the test user shows exactly the expected backend roles and no others.
Map backend roles to security roles and tenants
Map each backend role to a security role, such as index read or write permissions, and to the Dashboards tenants that team needs. Keep each mapping to the smallest set of permissions the team requires, and document the owning group for every rule. The engineer runs a role mapping check for each test user and compares index access and tenant visibility with the approved access matrix. The step closes when every test user's effective access matches that matrix.
Restrict REST API access to mapped admins
Limit security configuration endpoints and cluster-level admin actions to the admin roles, then confirm that other mapped users are refused when they call them. Keep the break-glass account for outage recovery only, and alert on any use. The security engineer runs a test matrix covering the mapped admin, a standard user and the break-glass account. The step closes when admin calls succeed for the mapped admin, return an authorization error for a standard user, and the break-glass use appears in the logs.

What drives SSO effort and how to keep each part down

This table lists the factors that most change the work of connecting OpenSearch and Dashboards to an identity provider, with what raises effort and how to hold each one down. Read each row as a lever you control before the build starts. The main takeaway is that naming, role design and a single pilot environment usually shrink effort more than any single technical choice.

Driver	What raises the effort	How to keep it down
Identity sources and federation	Several identity providers or directories, or direct LDAP or Active Directory binds alongside SAML or OpenID Connect, each with its own claim or attribute rules and failure modes.	Federate through one IdP where the organization allows it, and confirm which authentication backends the Security plugin will use before writing any config.
Group design in the directory	Inconsistent or nested group membership, personal groups, and names that do not say what access they grant, so mapping to backend roles becomes case-by-case.	Standardize group names with a shared prefix and a clear purpose, and agree the group list with the IdP team before mapping it to OpenSearch.
Number of roles and tenants	A new security role for every team or use case, with each role carrying its own index patterns, cluster permissions and tenant rights.	Keep a small set of role templates that differ only by index pattern, and map several groups to one role where the access is the same.
Dashboards tenants and index patterns	Many tenants or index patterns that must stay separate, each needing its own saved objects, role mapping and testing of what users can see.	Decide the separation model early, limit tenants to real isolation needs, and document which index patterns each tenant may read.
Multiple clusters and environments	Separate development, test and production clusters, each with its own IdP client registration, redirect URLs, certificates and role mappings that drift apart over time.	Build and verify the configuration in one non-production environment, then copy it to the others with only the endpoints and secrets changed.
Clients and service accounts on basic auth or tokens	Ingestion agents, scripts and dashboards that rely on basic authentication or tokens and must keep working while users move to SSO, so cutover needs a compatibility inventory.	Inventory every non-human client before cutover, give each its own service account with minimal roles, and move them in a planned order with a rollback path.
Audit and access review requirements	Evidence requests that need who had which role, when membership changed and how mappings were approved, which means logs and change records must be kept from day one.	Enable audit logging with agreed retention, store role mapping changes in version control, and schedule periodic access reviews with the IdP owners.
Team familiarity with the IdP and Security plugin	Limited experience with SAML metadata, OpenID Connect client settings or the Security plugin's configuration files, leading to repeated test cycles and vendor-specific troubleshooting.	Pair the IdP administrator with the platform engineer for the first build, and agree who owns each config file and each directory group before work starts.

How backend roles map to security roles and tenants

Access in OpenSearch follows a chain, and most access problems come from a broken link in it. The identity provider or directory authenticates the user and supplies a user name and group memberships. The Security plugin converts those groups into backend roles. Role mappings then link backend roles, users or hosts to security roles. A security role grants cluster permissions, index permissions on index patterns, and permissions on OpenSearch Dashboards tenants. Before any configuration, write the chain out as a table with one row per directory group, backend role, security role and tenant. That table becomes the document your reviewers check and the baseline for testing.

Index permissions and tenant permissions are separate, and teams often confuse them. Index permissions control which documents a search can return. Tenant permissions control which saved Dashboards objects, such as visualizations, dashboards and index patterns, a user can open or change. A user can therefore see a dashboard layout with no data behind it, or data with no saved objects to view it. Decide early whether teams share a tenant, get one tenant each, or use the Global tenant for shared content. Each choice changes how many security roles you maintain and who can edit shared dashboards.

Illustrative example: a directory group named payments-analysts is passed through as a backend role called payments_analysts. A role mapping links that backend role to a security role called payments_read. That security role grants read access to the index pattern payments-* and read access to a tenant called payments, and nothing else. Members of the group can search payments indices and open the payments tenant. They cannot write to either, and they cannot see indices outside the pattern. Wildcard index patterns are convenient, but check that a new index created by another team does not match them by accident.

When some users must see only part of a document, the next layer is document-level security, field-level security and field masking. Document-level security filters the documents a role can see, using a query. Field-level security hides named fields from a role. Field masking shows a field in a transformed form instead of its raw value. These features belong to the Security plugin and need planning up front: the fields that are sensitive, the queries that define visible documents, and the dashboards that will use them. Retrofitting them after users have built saved objects often breaks those objects. Confirm for your chosen version which of these features it includes and test how they behave with your aggregations and dashboards.

Mapping mistakes usually appear as missing data. Users sign in successfully, open Dashboards, and then see an empty index pattern or zero hits, because their backend roles do not match the security role that grants access. Trace the problem in order. First, confirm the group names the identity provider actually sends in the token or assertion. Second, check which backend roles the Security plugin assigned to that user, using the authentication information API for the current user. Third, check which role mappings matched. Fourth, check the index and tenant permissions on the security role. If audit logging is enabled, it helps confirm what was denied. Test each group with a dedicated test account before go-live.

How SSO setup changes on single node, HA and Kubernetes

A single node lab is the fastest place to prove the SSO handshake, but it hides problems that appear later. One host runs the OpenSearch node and Dashboards, so the redirect URL and certificate path are simple to follow. The OpenSearch install docs cover Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM and Debian packages, an Ansible playbook and Windows, and the method you choose changes where settings and secrets live. The main risk is copying lab shortcuts into production without changing them.

IdP reachability: The host must reach the IdP metadata URL or directory endpoints outbound. Confirm DNS and proxy settings from that host.
TLS certificates: Labs often use self-signed or internal CA certificates. Confirm the CA trust is installed where Dashboards runs and record the file that holds it.
Redirect URLs: Register the exact Dashboards URL, including port and path, with the IdP. Local names such as localhost usually cannot be used in production.
Break-glass: Keep an internal admin account in the security configuration so the cluster stays administrable when the IdP is down.

Before promoting any lab setting, list each change and confirm that your production install method can reproduce it.

Secrets, TLS and access controls for OpenSearch SSO

Once OpenSearch and OpenSearch Dashboards trust an external identity provider or directory, the identity path becomes one of the most sensitive parts of the cluster. The controls below cover the credentials, encrypted connections, directory permissions, administrative boundaries and logging that keep that path safe, and each one should be confirmed in the target environment before go-live.

Encrypt every identity connection

TLS should cover node-to-node and client traffic in the Security plugin, and also the connection from OpenSearch Dashboards and the cluster to the IdP or directory. Without it, login tokens, bind credentials and user attributes can cross the network in readable form. Check that certificates validate against your internal CA, that hostname verification is on, and that the rotation process is written down with an owner and a calendar reminder.

Keep secrets out of version control

IdP client secrets, LDAP bind passwords and private keys used for SAML signing or TLS should never appear in configuration files committed to Git. Store them in the secret store your organization already operates, inject them at deployment time, and restrict who can read them. Confirm that old commits and CI logs do not contain them, and that a secret leak triggers a rotation runbook rather than a manual search.

Least-privilege directory bind account

The account OpenSearch uses to search LDAP or Active Directory should be a dedicated service account that can read only the user, group and attribute data needed to map backend roles. It should not be a domain administrator or a general-purpose user. Ask the directory team to confirm the account is read-only, cannot change group membership, and has a password policy that matches your rotation schedule.

Limit who changes Security configuration

Changes to authentication backends, role mappings and tenant settings alter who can reach which data. Restrict the Security plugin configuration API and the Dashboards security pages to a small named group of administrators, and require changes to pass through version control or a change ticket. Verify that ordinary analysts and application accounts cannot modify role mappings or disable an authentication backend.

Protect the break-glass admin account

The internal admin account in the Security plugin is the recovery path when the IdP is unavailable, so it needs a long, unique password stored in a sealed vault and rotated after each use. Keep its use limited to documented recovery procedures, and confirm that alerts fire on any login with that account. Test the recovery procedure on a non-production cluster so that the first real use is not also the first test.

Audit logins, failures and changes

Enable the Security plugin audit logs for authentication successes, authentication failures and configuration changes, and forward them to a location outside the cluster. Failed logins from the IdP path reveal misconfigured bind accounts, expired certificates and credential stuffing, so they need the same attention as successful access. Confirm retention meets your policy and that someone reviews the logs on a defined schedule.

Restrict the REST API to admin roles

The REST API exposes cluster settings and Security plugin endpoints that let an authenticated caller change how the cluster trusts identities. Limit access to these endpoints to admin roles, and keep application and analyst roles on index and search permissions only. Check that network policies also block direct access from user subnets, so that the API is not reachable even with a valid login.

How to test that SSO works and fails safely

Test the SSO integration as a set of expected outcomes, not as a single login check. Before you run anything, write down what each test user should see: which OpenSearch Dashboards tenant opens, which index patterns are visible, which backend roles the Security plugin assigns, and what the audit log should record. Record these expectations in a test matrix that names the identity provider group, the mapped backend role, the security role and the tenant. Testers then compare observed results against the matrix rather than judging whether the page 'looks right'. This also gives your security reviewers a document they can sign off before go-live.

Start with the positive and negative access paths. Log in once for each mapped group and each tenant, and confirm the user lands in the correct tenant with the expected index permissions. Then test a user who belongs to no mapped group. That user should be denied at the identity layer or should reach OpenSearch with no useful roles, depending on how your mapping is built. Next, use a user from group A to try to open tenant B and to query an index pattern that belongs to group B. Also check document-level and field-level restrictions where you have configured them, by searching for a document the user should not see and confirming that restricted fields are absent or masked in results, not just hidden in the Dashboards interface.

Test the offboarding path, which is where many deployments fail quietly. Disable a test account in the directory, expire it, or remove its group membership, then confirm that the user loses access once existing sessions and cached tokens end. Measure how long this takes against your organization's stated requirement, and record the result. Confirm the break-glass admin account still works when the identity provider is unavailable. This account should be an internal user defined in the Security plugin configuration, protected by a strong credential stored under dual control, and used only for emergencies. Test the login, then confirm it is logged and that its use triggers your alerting process.

Test the failure modes on purpose. Each one should fail closed, meaning users are denied and an error is logged, not granted broader access. Check these cases: a wrong redirect or callback URL in the identity provider registration, which should block login with a clear error; clock skew between OpenSearch nodes and the identity provider, which can cause token validation to fail, so confirm the time tolerance and time synchronization; missing group or role claims, where users should receive no mapped roles rather than default admin access; a directory outage, where you confirm the behavior of LDAP or Active Directory lookups and that the break-glass path still works; and certificate expiry for the SAML signing certificate, the OpenID Connect provider's TLS certificate or the LDAP connection, using a test certificate with a short lifetime.

Log the outcomes and make the test plan repeatable. Confirm that failed logins, denied access attempts and changes to security configuration appear in the audit logs, with user, time, source and action recorded, and that those logs are forwarded to your central store. Record the OpenSearch and OpenSearch Dashboards versions with each run. Run the same suite after every upgrade and after any change to the identity provider, group mappings or Security plugin configuration, because minor-version releases and identity provider changes can alter claim names or token behavior. Confirm the specifics of each identity provider's claim formats and token lifetimes with the vendor and with your own environment before you finalize the expected results.

Questions teams ask before bringing in help for OpenSearch SSO

How much does outside help for OpenSearch SSO cost?

Cost depends on how many identity sources, groups and tenants the work touches, and on how settled your role design already is. The effort usually splits into discovery, configuration of the Security plugin for each authentication backend, role and tenant mapping, login testing and handover. Most of that is one-time work, while staff time for role changes and upgrades recurs. DeployOpen does not publish a price list. Its engagements are fixed-scope, so a quote follows a written scope that lists the identity sources, the role model, the environments and the deliverables. Ask any provider to itemize discovery, build, testing and handover, and to state what is excluded, such as changes to the identity provider that your directory team makes. The OpenSearch software is released under the Apache License, Version 2.0, so the software itself adds no line to the quote.

Can our own team set up OpenSearch SSO without outside help?

Yes, for a single identity source with clear groups that map directly onto roles. A team that already runs OpenSearch and has an identity provider administrator available can work from the OpenSearch security documentation and complete a first configuration. The work gets harder with several identity sources, such as SAML for employees and LDAP for contractors, with many tenants that have overlapping access, or with strict audit requirements that call for documented role decisions and evidence. The main risk sits in the mapping: one wrong backend role can give a user access to another team's indices or saved objects. Check whether your engineers have tested tenant isolation in Dashboards and field-level rules, and whether they can rebuild the configuration from source control after an upgrade. A written scope from a provider helps you compare that effort with your own staffing before you decide.

What does an SSO project need from our identity and directory team?

Plan for access, test accounts, a certificate process and a change window. Someone must administer the identity provider or directory, because the OpenSearch side depends on the claims or groups the provider sends. Your team should supply a registered test application or client for a non-production cluster, test accounts that cover each role and tenant, and the group memberships the mapping will use. SAML work needs signing and metadata certificates, so confirm how they are issued, rotated and approved. OpenSearch uses TLS for node and client traffic, so certificate ownership should be settled early. Agree on a change window for the production cutover and a rollback plan if logins fail. Ask the provider to list each dependency in the written scope with a named owner, so delays on your side show up before testing begins.

How does the number of identity sources change the timeline?

The timeline depends mainly on the number of identity sources, the number of distinct roles and tenants, and how clean the group data is. Each added source brings its own configuration, claim or attribute checks and login testing. Role design often takes longer than teams expect, because backend roles must map to security roles and each tenant's Dashboards access must be confirmed for each group. Clean, well-owned groups shorten the work. Nested or overlapping groups, duplicate accounts and undocumented ownership lengthen it. Testing often takes as long as the configuration, since each role should be exercised from a real login. A duration follows from the written scope, so ask a provider to break the estimate into identity sources, role and tenant mapping, testing and handover. Also ask which items depend on an input from your team on a fixed date.

Does single sign-on change the OpenSearch license cost?

The OpenSearch software is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition, so enabling SSO backends in the Security plugin adds no software license fee. Costs still appear elsewhere. Your identity provider may charge per user or for features such as SAML or OpenID Connect support, depending on the product and plan, so confirm that with the identity vendor. Staff time for planning, configuration, testing and support is a separate cost, mostly one-time for the build and recurring for role changes and upgrades. Hosting for the cluster and any certificate tooling also sit outside the OpenSearch license. When you request a quote, separate the provider's fee from the costs your organization carries, and list the identity licensing questions your procurement team needs to resolve before work starts.

What happens to OpenSearch SSO settings during an upgrade?

SSO configuration should be checked on every upgrade and tested before the production change. OpenSearch targets a new minor version about every eight weeks, and each version stays in maintenance, where it receives bug fixes and security patches but no new features. Identity provider metadata, certificates, Security plugin settings and role mappings all live in the cluster and can be affected by a version change. Keep the security configuration in version control so it can be reapplied, and run a login test with each test account against a staging cluster on the target version before the production upgrade. Major version moves, such as 2.x to 3.x, need a separate plan that covers plugin compatibility. Ask whether upgrade testing for SSO is part of a fixed scope or sits in an ongoing retainer, since support, upgrades and continuous testing are available as retainers.

Which authentication backends does OpenSearch Security support for SSO?

The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. For browser sign-in to OpenSearch Dashboards with a central identity provider, SAML and OpenID Connect are the common choices. LDAP and Active Directory connect directly to a directory. Choose based on what your organization already runs and what your team can operate safely. Each backend has its own settings for endpoints, certificates, claims or attributes and group handling, so a mixed deployment multiplies that configuration. Confirm the exact settings and any version-specific behavior in the OpenSearch security documentation for the version you will run. Kerberos and JWT are less common for Dashboards sign-in, so confirm the client path your users need before choosing them. Test each backend with a real account before cutover, and plan the TLS settings for each connection from the start.

How do backend roles map to security roles and tenants?

Backend roles come from the identity source, such as directory groups or identity provider claims. The Security plugin maps them to security roles through role mappings. A security role then grants index permissions, document and field-level security rules and Dashboards tenant access. Tenants separate saved objects such as dashboards and visualizations, so each team's views stay apart. Build the model from the access each team needs, then check it against the directory structure. Name each role for the job it grants, document which backend roles map to it, and keep the mapping in version control. Test each role with a login from a matching test account, and confirm that a user in one group cannot see another team's indices or tenant. Field masking and audit logs can support stricter requirements, but confirm with your compliance team which controls they need as evidence. DeployOpen designs this model within a written scope, and it prepares evidence for assessments without issuing audit reports or certifications.

How DeployOpen works on this

DeployOpen plans, implements, documents and supports self-hosted OpenSearch inside your own cloud accounts, data centers or air-gapped networks. For SSO and identity integration, we start from the identity provider, the roles your teams already use and the access rules your auditors expect, then configure the Security plugin to match.

How we scope

Inventory the identity sources in use, such as SAML, OpenID Connect, Active Directory or LDAP, and who owns each one
Map existing groups and claims to OpenSearch backend roles, security roles and tenants in a written matrix
Confirm which OpenSearch Dashboards tenants, index patterns and document-level rules each user population needs
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts

How we build

Configure the authentication backends in the Security plugin in a non-production cluster first
Set up role mappings so group membership grants only the index and Dashboards permissions listed in the matrix
Test each login path, including session expiry, logout and users who belong to several groups
Keep identity configuration in version-controlled files so changes can be reviewed and repeated

How we hand over

Provide the final role mapping matrix, configuration files and a record of the test cases and results
Document the steps to add a group, remove a user and rotate identity provider certificates or secrets
Walk through the runbook with your identity, security and platform engineers before cutover
Agree which parts of the work your team will own after handover and which remain under retainer

How we support

Review identity configuration again when OpenSearch moves to a new minor or major version
Retest SSO logins and role mappings after identity provider changes or directory restructuring
Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing
Ask any partner which OpenSearch version and maintenance status your SSO setup will target, and confirm it against the release page

OpenSearch SSO and identity integration