Authentication Backends, LDAP/OIDC/SAML-Like Integrations, Dashboards Multi-Tenancy, and Impersonation Concepts

Learning outcomes

AtlasMart’s production identities live in a corporate identity provider, while local lab users live in the Security plugin’s internal database. Copying local users into production would duplicate password lifecycle and offboarding. This lesson separates the authentication backend that proves identity from role mappings that authorize it, then explains where LDAP, OIDC, SAML, tenants and impersonation fit.

1. Authentication is a pipeline

The Security plugin receives credentials, passes them through configured authentication domains in order, verifies them against the selected backend, optionally collects backend roles, then maps the resulting user/backend roles to OpenSearch security roles. A successfully authenticated identity can still have zero useful permissions when mappings do not match.

2. Chain backends deliberately

config:
  dynamic:
    authc:
      basic_internal_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal

      oidc_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: openid
          challenge: true
          config:
            subject_key: preferred_username
            roles_key: roles
            openid_connect_url: https://idp.example/.well-known/openid-configuration
        authentication_backend:
          type: noop

The first domain above keeps a controlled basic-auth path for APIs/administration while OIDC handles browser/token identities. The exact configuration must be validated against your IdP. TLS to the IdP, hostname verification and key rollover are part of the identity trust chain.

3. SAML is not a generic API token

OpenSearch’s SAML integration implements the web-browser SSO profile and is primarily used with OpenSearch Dashboards. It is not the credential format you should hand to a headless bulk loader. Keep a compatible API authentication domain—such as internal/basic for a lab, LDAP-backed Basic, JWT/client certificate, or OpenSearch API keys depending on the machine use case.

4. Dashboards multi-tenancy isolates saved objects

A tenant is a namespace for OpenSearch Dashboards saved objects. Global, private and custom tenants can separate dashboards and visualizations. They do not replace index permissions, DLS or FLS. This distinction matters during incident response: a tenant mistake may expose saved objects; an index-role mistake may expose underlying data through any client.

PUT _plugins/_security/api/tenants/atlasmart_ops
{
  "description": "AtlasMart operations dashboards"
}

PUT _plugins/_security/api/roles/atlasmart_ops_viewer
{
  "cluster_permissions": ["cluster_composite_ops_ro"],
  "index_permissions": [{
    "index_patterns": ["atlasmart-products-secure-v1"],
    "allowed_actions": ["read"]
  }],
  "tenant_permissions": [{
    "tenant_patterns": ["atlasmart_ops"],
    "allowed_actions": ["kibana_all_read"]
  }]
}

The OpenSearch Dashboards server also needs its own service identity and permissions. Do not assign the built-in kibana_server role to human users.

5. Impersonation is delegated authority, not a convenience header

OpenSearch supports controlled user impersonation for REST and transport scenarios. A privileged authenticated principal can submit a request as another configured user. That is useful for support/testing, but a wildcard target list turns a troubleshooting feature into broad delegated authority.

plugins.security.authcz.rest_impersonation_user:
  atlasmart_support_admin:
    - atlasmart_reader_user
    - atlasmart_analyst_user

curl -k -u "$SUPPORT_USER:$SUPPORT_PASSWORD"   -H 'opendistro_security_impersonate_as: atlasmart_reader_user'   https://localhost:9201/_plugins/_security/authinfo?pretty

Audit both the authenticated actor and effective identity where the event format provides them. Never let ordinary application identities impersonate arbitrary users.

6. Wrong approach: map a broad directory group to all_access

A corporate group such as employees is convenient but usually far broader than an OpenSearch administrative role. Map narrowly governed groups such as atlasmart-search-readers to dedicated security roles. Test offboarding and group removal so access disappears when the source identity changes.

7. Production judgment

Identity availability becomes part of search availability. Define what happens when LDAP/IdP is down, how token clock skew/key rotation works, how emergency administration is performed, and which login path is intentionally non-interactive. Monitor authentication failures without logging secrets. For managed services, identity and tenancy may be integrated with provider IAM or hosted SSO and differ from upstream plugin configuration.

References

• OpenSearch 3.8 release/version history — Pinned OpenSearch 3.8.0 release baseline.
• OpenSearch Security overview — Security-plugin architecture, TLS, authentication and authorization overview.
• Configure TLS certificates — Transport/HTTP TLS, node DNs and admin certificate concepts.
• Apply Security configuration safely — Security-index initialization, backup and narrow apply guidance.
• Security APIs — Internal users, roles, mappings, tenants, certificate and related APIs.
• Users and roles — Internal users, roles, role mappings and built-in roles.
• Authentication backends — Authentication flow and chained backend concepts.
• Multi-tenancy — OpenSearch Dashboards tenant mechanics and permissions.
• Document-level security — DLS read filtering and limitations.
• Field-level security — FLS include/exclude semantics and interactions.
• Audit logs — Security audit categories, storage and enablement.
• API keys — OpenSearch 3.7+ scoped API-key lifecycle and limitations.
• OpenSearch downloads/license — Current distribution and Apache-2.0 licensing context.