Set up Enterprise Search with OpenID Connect single sign-on (SSO)
editSet up Enterprise Search with OpenID Connect single sign-on (SSO)
editThis feature is not available for all Elastic subscription levels. Refer to the subscriptions pages for Elastic Cloud and Elastic Stack. To change your subscription level or start a trial, see Elastic subscription.
The following documentation describes the process of configuring Elasticsearch and Kibana:
Within your Enterprise Search configuration settings, make sure that:
-
kibana.host
is set -
kibana.external_url
is set -
any
auth.source
configurations are removed.
Configure Enterprise Search role mappings for OpenID Connect users
editWhen you configured Elasticsearch and Kibana for OpenID Connect using the documentation links above, one of the steps advised you to create a role mapping to be able to access Kibana. As a very simple and permissive example, you can give all users in oidc1
realm superuser
role, and that will also give them full access to App Search and Workplace Search:
PUT /_security/role_mapping/oidc1_mapping { "roles": [ "superuser" ], "enabled": true, "rules": { "all": [ {"field": { "realm.name": "oidc1"}}} ] } }
However, this might be too permissive. In the following example, users who successfully log in to the oidc1
realm get full access to Kibana, but no access to Enterprise Search:
PUT /_security/role_mapping/oidc1_mapping { "roles": [ "kibana_admin" ], "enabled": true, "rules": { "all": [ {"field": { "realm.name": "oidc1"}}} ] } }
In this case, oidc1
users can be managed via Enterprise Search mappings. Before any mappings can be created, it is necessary to enable role-based access (RBAC) mode in either App Search or Workplace Search. After that, users can be mapped in Users and Roles:
Mapping can use common Elasticsearch user attributes, such as username
and email
, but also anything provided in metadata
that is returned by an OIDC provider. The data returned by an OIDC provider depends on what scopes were requested. For example, when openid
and email
scopes are requested, the Google OpenID Connect provider returns the following metadata:
{ "oidc(hd)": "example.com", "oidc(id_token_hint)": "abcdef", "oidc(iss)": "https://accounts.google.com", "oidc(email)": "john.smith@example.com", "oidc(email_verified)": true, "oidc(sub)": "123456789", "oidc(azp)": "app-id-here.apps.googleusercontent.com", "oidc(at_hash)": "xyz", "oidc(picture)": "https://lh3.googleusercontent.com/some-picture", "oidc(nonce)": "xxx", "oidc(aud)": [ "app-id-here.apps.googleusercontent.com" ] }
This metadata can be extracted and assigned to Elasticsearch user’s properties. For example, this snippet in elasticsearch.yml
:
xpack: security: authc: realms: oidc: oidc1: order: 2 claims.principal: email claim_patterns.principal: "^([^@]+)@example\\.com$" claims.mail: email # more settings...
-
extracts
email
and assigns part of it to the Elasticsearch user’susername
(principal
) using a pattern -
also assigns
email
as-is to the Elasticsearch user’semail
. Then, theseusername
andemail
properties, as well as the Elasticsearch user’srole
andmetadata
, can be used to create a mapping specific to App Search or Workplace search.
Note that the snippet above is only a partial example of settings. For a full set of settings related to OpenID Connect, see the Elasticsearch documentation.