- Elasticsearch Guide: other versions:
- What is Elasticsearch?
- What’s new in 7.10
- Getting started with Elasticsearch
- Set up Elasticsearch
- Installing Elasticsearch
- Configuring Elasticsearch
- Setting JVM options
- Secure settings
- Auditing settings
- Circuit breaker settings
- Cluster-level shard allocation and routing settings
- Cross-cluster replication settings
- Discovery and cluster formation settings
- Field data cache settings
- HTTP
- Index lifecycle management settings
- Index management settings
- Index recovery settings
- Indexing buffer settings
- License settings
- Local gateway settings
- Logging
- Machine learning settings
- Monitoring settings
- Node
- Network settings
- Node query cache settings
- Search settings
- Security settings
- Shard request cache settings
- Snapshot lifecycle management settings
- Transforms settings
- Transport
- Thread pools
- Watcher settings
- Important Elasticsearch configuration
- Important System Configuration
- Bootstrap Checks
- Heap size check
- File descriptor check
- Memory lock check
- Maximum number of threads check
- Max file size check
- Maximum size virtual memory check
- Maximum map count check
- Client JVM check
- Use serial collector check
- System call filter check
- OnError and OnOutOfMemoryError checks
- Early-access check
- G1GC check
- All permission check
- Discovery configuration check
- Bootstrap Checks for X-Pack
- Starting Elasticsearch
- Stopping Elasticsearch
- Discovery and cluster formation
- Add and remove nodes in your cluster
- Full-cluster restart and rolling restart
- Remote clusters
- Set up X-Pack
- Configuring X-Pack Java Clients
- Plugins
- Upgrade Elasticsearch
- Index modules
- Mapping
- Text analysis
- Overview
- Concepts
- Configure text analysis
- Built-in analyzer reference
- Tokenizer reference
- Token filter reference
- Apostrophe
- ASCII folding
- CJK bigram
- CJK width
- Classic
- Common grams
- Conditional
- Decimal digit
- Delimited payload
- Dictionary decompounder
- Edge n-gram
- Elision
- Fingerprint
- Flatten graph
- Hunspell
- Hyphenation decompounder
- Keep types
- Keep words
- Keyword marker
- Keyword repeat
- KStem
- Length
- Limit token count
- Lowercase
- MinHash
- Multiplexer
- N-gram
- Normalization
- Pattern capture
- Pattern replace
- Phonetic
- Porter stem
- Predicate script
- Remove duplicates
- Reverse
- Shingle
- Snowball
- Stemmer
- Stemmer override
- Stop
- Synonym
- Synonym graph
- Trim
- Truncate
- Unique
- Uppercase
- Word delimiter
- Word delimiter graph
- Character filters reference
- Normalizers
- Index templates
- Data streams
- Ingest node
- Search your data
- Query DSL
- Aggregations
- Bucket aggregations
- Adjacency matrix
- Auto-interval date histogram
- Children
- Composite
- Date histogram
- Date range
- Diversified sampler
- Filter
- Filters
- Geo-distance
- Geohash grid
- Geotile grid
- Global
- Histogram
- IP range
- Missing
- Nested
- Parent
- Range
- Rare terms
- Reverse nested
- Sampler
- Significant terms
- Significant text
- Terms
- Variable width histogram
- Subtleties of bucketing range fields
- Metrics aggregations
- Pipeline aggregations
- Bucket aggregations
- EQL
- SQL access
- Overview
- Getting Started with SQL
- Conventions and Terminology
- Security
- SQL REST API
- SQL Translate API
- SQL CLI
- SQL JDBC
- SQL ODBC
- SQL Client Applications
- SQL Language
- Functions and Operators
- Comparison Operators
- Logical Operators
- Math Operators
- Cast Operators
- LIKE and RLIKE Operators
- Aggregate Functions
- Grouping Functions
- Date/Time and Interval Functions and Operators
- Full-Text Search Functions
- Mathematical Functions
- String Functions
- Type Conversion Functions
- Geo Functions
- Conditional Functions And Expressions
- System Functions
- Reserved keywords
- SQL Limitations
- Scripting
- Data management
- ILM: Manage the index lifecycle
- Overview
- Concepts
- Automate rollover
- Manage Filebeat time-based indices
- Index lifecycle actions
- Configure a lifecycle policy
- Migrate index allocation filters to node roles
- Resolve lifecycle policy execution errors
- Start and stop index lifecycle management
- Manage existing indices
- Skip rollover
- Restore a managed data stream or index
- Monitor a cluster
- Frozen indices
- Roll up or transform your data
- Set up a cluster for high availability
- Snapshot and restore
- Secure a cluster
- Overview
- Configuring security
- User authentication
- Built-in users
- Internal users
- Token-based authentication services
- Realms
- Realm chains
- Active Directory user authentication
- File-based user authentication
- LDAP user authentication
- Native user authentication
- OpenID Connect authentication
- PKI user authentication
- SAML authentication
- Kerberos authentication
- Integrating with other authentication systems
- Enabling anonymous access
- Controlling the user cache
- Configuring SAML single-sign-on on the Elastic Stack
- Configuring single sign-on to the Elastic Stack using OpenID Connect
- User authorization
- Built-in roles
- Defining roles
- Granting access to Stack Management features
- Security privileges
- Document level security
- Field level security
- Granting privileges for data streams and index aliases
- Mapping users and groups to roles
- Setting up field and document level security
- Submitting requests on behalf of other users
- Configuring authorization delegation
- Customizing roles and authorization
- Enabling audit logging
- Encrypting communications
- Restricting connections with IP filtering
- Cross cluster search, clients, and integrations
- Tutorial: Getting started with security
- Tutorial: Encrypting communications
- Troubleshooting
- Some settings are not returned via the nodes settings API
- Authorization exceptions
- Users command fails due to extra arguments
- Users are frequently locked out of Active Directory
- Certificate verification fails for curl on Mac
- SSLHandshakeException causes connections to fail
- Common SSL/TLS exceptions
- Common Kerberos exceptions
- Common SAML issues
- Internal Server Error in Kibana
- Setup-passwords command fails due to connection failure
- Failures due to relocation of the configuration files
- Limitations
- Watch for cluster and index events
- Command line tools
- How To
- Glossary of terms
- REST APIs
- API conventions
- Compact and aligned text (CAT) APIs
- cat aliases
- cat allocation
- cat anomaly detectors
- cat count
- cat data frame analytics
- cat datafeeds
- cat fielddata
- cat health
- cat indices
- cat master
- cat nodeattrs
- cat nodes
- cat pending tasks
- cat plugins
- cat recovery
- cat repositories
- cat segments
- cat shards
- cat snapshots
- cat task management
- cat templates
- cat thread pool
- cat trained model
- cat transforms
- Cluster APIs
- Cluster allocation explain
- Cluster get settings
- Cluster health
- Cluster reroute
- Cluster state
- Cluster stats
- Cluster update settings
- Nodes feature usage
- Nodes hot threads
- Nodes info
- Nodes reload secure settings
- Nodes stats
- Pending cluster tasks
- Remote cluster info
- Task management
- Voting configuration exclusions
- Cross-cluster replication APIs
- Data stream APIs
- Document APIs
- Enrich APIs
- Graph explore API
- Index APIs
- Add index alias
- Analyze
- Clear cache
- Clone index
- Close index
- Create index
- Delete index
- Delete index alias
- Delete component template
- Delete index template
- Delete index template (legacy)
- Flush
- Force merge
- Freeze index
- Get component template
- Get field mapping
- Get index
- Get index alias
- Get index settings
- Get index template
- Get index template (legacy)
- Get mapping
- Index alias exists
- Index exists
- Index recovery
- Index segments
- Index shard stores
- Index stats
- Index template exists (legacy)
- Open index
- Put index template
- Put index template (legacy)
- Put component template
- Put mapping
- Refresh
- Rollover index
- Shrink index
- Simulate index
- Simulate template
- Split index
- Synced flush
- Type exists
- Unfreeze index
- Update index alias
- Update index settings
- Resolve index
- List dangling indices
- Import dangling index
- Delete dangling index
- Index lifecycle management APIs
- Ingest APIs
- Info API
- Licensing APIs
- Machine learning anomaly detection APIs
- Add events to calendar
- Add jobs to calendar
- Close jobs
- Create jobs
- Create calendars
- Create datafeeds
- Create filters
- Delete calendars
- Delete datafeeds
- Delete events from calendar
- Delete filters
- Delete forecasts
- Delete jobs
- Delete jobs from calendar
- Delete model snapshots
- Delete expired data
- Estimate model memory
- Find file structure
- Flush jobs
- Forecast jobs
- Get buckets
- Get calendars
- Get categories
- Get datafeeds
- Get datafeed statistics
- Get influencers
- Get jobs
- Get job statistics
- Get machine learning info
- Get model snapshots
- Get overall buckets
- Get scheduled events
- Get filters
- Get records
- Open jobs
- Post data to jobs
- Preview datafeeds
- Revert model snapshots
- Set upgrade mode
- Start datafeeds
- Stop datafeeds
- Update datafeeds
- Update filters
- Update jobs
- Update model snapshots
- Machine learning data frame analytics APIs
- Create data frame analytics jobs
- Create trained models
- Update data frame analytics jobs
- Delete data frame analytics jobs
- Delete trained models
- Evaluate data frame analytics
- Explain data frame analytics
- Get data frame analytics jobs
- Get data frame analytics jobs stats
- Get trained models
- Get trained models stats
- Start data frame analytics jobs
- Stop data frame analytics jobs
- Migration APIs
- Reload search analyzers API
- Repositories metering APIs
- Rollup APIs
- Search APIs
- Searchable snapshots APIs
- Security APIs
- Authenticate
- Change passwords
- Clear cache
- Clear roles cache
- Clear privileges cache
- Clear API key cache
- Create API keys
- Create or update application privileges
- Create or update role mappings
- Create or update roles
- Create or update users
- Delegate PKI authentication
- Delete application privileges
- Delete role mappings
- Delete roles
- Delete users
- Disable users
- Enable users
- Get API key information
- Get application privileges
- Get builtin privileges
- Get role mappings
- Get roles
- Get token
- Get users
- Grant API keys
- Has privileges
- Invalidate API key
- Invalidate token
- OpenID Connect prepare authentication
- OpenID Connect authenticate
- OpenID Connect logout
- SAML prepare authentication
- SAML authenticate
- SAML logout
- SAML invalidate
- SSL certificate
- Snapshot and restore APIs
- Snapshot lifecycle management APIs
- Transform APIs
- Usage API
- Watcher APIs
- Definitions
- Migration guide
- Release notes
- Elasticsearch version 7.10.2
- Elasticsearch version 7.10.1
- Elasticsearch version 7.10.0
- Elasticsearch version 7.9.3
- Elasticsearch version 7.9.2
- Elasticsearch version 7.9.1
- Elasticsearch version 7.9.0
- Elasticsearch version 7.8.1
- Elasticsearch version 7.8.0
- Elasticsearch version 7.7.1
- Elasticsearch version 7.7.0
- Elasticsearch version 7.6.2
- Elasticsearch version 7.6.1
- Elasticsearch version 7.6.0
- Elasticsearch version 7.5.2
- Elasticsearch version 7.5.1
- Elasticsearch version 7.5.0
- Elasticsearch version 7.4.2
- Elasticsearch version 7.4.1
- Elasticsearch version 7.4.0
- Elasticsearch version 7.3.2
- Elasticsearch version 7.3.1
- Elasticsearch version 7.3.0
- Elasticsearch version 7.2.1
- Elasticsearch version 7.2.0
- Elasticsearch version 7.1.1
- Elasticsearch version 7.1.0
- Elasticsearch version 7.0.0
- Elasticsearch version 7.0.0-rc2
- Elasticsearch version 7.0.0-rc1
- Elasticsearch version 7.0.0-beta1
- Elasticsearch version 7.0.0-alpha2
- Elasticsearch version 7.0.0-alpha1
- Dependencies and versions
Configure Elasticsearch for OpenID Connect authentication
editConfigure Elasticsearch for OpenID Connect authentication
editThe following is a summary of the configuration steps required in order to enable authentication using OpenID Connect in Elasticsearch:
Enable TLS for HTTP
editIf your Elasticsearch cluster is operating in production mode, then you must configure the HTTP interface to use SSL/TLS before you can enable OpenID Connect authentication.
For more information, see Encrypting HTTP client communications.
Enable the token service
editThe Elasticsearch OpenID Connect implementation makes use of the Elasticsearch Token Service. This service
is automatically enabled if you configure TLS on the HTTP interface, and can be
explicitly configured by including the following in your elasticsearch.yml
file:
xpack.security.authc.token.enabled: true
Create an OpenID Connect realm
editOpenID Connect based authentication is enabled by configuring the appropriate realm within the authentication chain for Elasticsearch.
This realm has a few mandatory settings, and a number of optional settings. The available settings are described in detail in OpenID Connect realm settings. This guide will explore the most common settings.
Create an OpenID Connect (the realm type is oidc
) realm in your elasticsearch.yml
file
similar to what is shown below:
The values used below are meant to be an example and are not intended to apply to every use case. The details below the configuration snippet provide insights and suggestions to help you pick the proper values, depending on your OP configuration.
xpack.security.authc.realms.oidc.oidc1: order: 2 rp.client_id: "the_client_id" rp.response_type: code rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback" op.issuer: "https://op.example.org" op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize" op.token_endpoint: "https://op.example.org/oauth2/v1/token" op.jwkset_path: oidc/jwkset.json op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo" op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout" rp.post_logout_redirect_uri: "https://kibana.example.org:5601/logged_out" claims.principal: sub claims.groups: "http://example.info/claims/groups"
The configuration values used in the example above are:
- xpack.security.authc.realms.oidc.oidc1
-
This defines a new
oidc
authentication realm named "oidc1". See Realms for more explanation of realms. - order
- You should define a unique order on each realm in your authentication chain. It is recommended that the OpenID Connect realm be at the bottom of your authentication chain (that is, that it has the highest order).
- rp.client_id
- This, usually opaque, arbitrary string, is the Client Identifier that was assigned to the Elastic Stack RP by the OP upon registration.
- rp.response_type
-
This is an identifier that controls which OpenID Connect authentication flow this RP supports and also which flow this RP requests the OP should follow. Supported values are
-
code
, which means that the RP wants to use the Authorization Code flow. If your OP supports the Authorization Code flow, you should select this instead of the Implicit Flow. -
id_token token
which means that the RP wants to use the Implicit flow and we also request an oAuth2 access token from the OP, that we can potentially use for follow up requests ( UserInfo ). This should be selected if the OP offers a UserInfo endpoint in its configuration, or if you know that the claims you will need to use for role mapping are not available in the ID Token. -
id_token
which means that the RP wants to use the Implicit flow, but is not interested in getting an oAuth2 token too. Select this if you are certain that all necessary claims will be contained in the ID Token or if the OP doesn’t offer a User Info endpoint.
-
- rp.redirect_uri
-
The redirect URI where the OP will redirect the browser after authentication. This needs to be
exactly the same as the one configured with the OP upon registration and will
typically be
${kibana-url}/api/security/oidc/callback
where ${kibana-url} is the base URL for your Kibana instance - op.issuer
- A verifiable Identifier for your OpenID Connect Provider. An Issuer Identifier is usually a case sensitive URL. The value for this setting should be provided by your OpenID Connect Provider.
- op.authorization_endpoint
- The URL for the Authorization Endpoint in the OP. This is where the user’s browser will be redirected to start the authentication process. The value for this setting should be provided by your OpenID Connect Provider.
- op.token_endpoint
- The URL for the Token Endpoint in the OpenID Connect Provider. This is the endpoint where Elasticsearch will send a request to exchange the code for an ID Token. This setting is optional when you use the implicit flow. The value for this setting should be provided by your OpenID Connect Provider.
- op.jwkset_path
- The path to a file or a URL containing a JSON Web Key Set with the key material that the OpenID Connect Provider uses for signing tokens and claims responses. If a path is set, it is resolved relative to the Elasticsearch config directory. Elasticsearch will automatically monitor this file for changes and will reload the configuration whenever it is updated. Your OpenID Connect Provider should provide you with this file or a URL where it is available.
- op.userinfo_endpoint
- (Optional) The URL for the UserInfo Endpoint in the OpenID Connect Provider. This is the endpoint of the OP that can be queried to get further user information, if required. The value for this setting should be provided by your OpenID Connect Provider.
- op.endsession_endpoint
- (Optional) The URL to the End Session Endpoint in the OpenID Connect Provider. This is the endpoint where the user’s browser will be redirected after local logout, if the realm is configured for RP initiated Single Logout and the OP supports it. The value for this setting should be provided by your OpenID Connect Provider.
- rp.post_logout_redirect_uri
-
(Optional) The Redirect URL where the OpenID Connect Provider should redirect the user after a
successful Single Logout (assuming
op.endsession_endpoint
above is also set). This should be set to a value that will not trigger a new OpenID Connect Authentication, such as${kibana-url}/logged_out
where ${kibana-url} is the base URL for your Kibana instance. - claims.principal
- See Claims mapping.
- claims.groups
- See Claims mapping.
A final piece of configuration of the OpenID Connect realm is to set the Client Secret
that was assigned
to the RP during registration in the OP. This is a secure setting and as such is not defined in the realm
configuration in elasticsearch.yml
but added to the elasticsearch keystore.
For instance
bin/elasticsearch-keystore add xpack.security.authc.realms.oidc.oidc1.rp.client_secret
According to the OpenID Connect specification, the OP should also make their configuration
available at a well known URL, which is the concatenation of their Issuer
value with the
.well-known/openid-configuration
string. For example: https://op.org.com/.well-known/openid-configuration
That document should contain all the necessary information to configure the OpenID Connect realm in Elasticsearch.
Claims mapping
editClaims and scopes
editWhen authenticating to Kibana using OpenID Connect, the OP will provide information about the user
in the form of OpenID Connect Claims, that can be included either in the ID Token, or be retrieved from the
UserInfo endpoint of the OP. The claim is defined as a piece of information asserted by the OP
for the authenticated user. Simply put, a claim is a name/value pair that contains information about
the user. Related to claims, we also have the notion of OpenID Connect Scopes. Scopes are identifiers
that are used to request access to specific lists of claims. The standard defines a set of scope
identifiers that can be requested. The only mandatory one is openid
, while commonly used ones are
profile
and email
. The profile
scope requests access to the name
,family_name
,given_name
,middle_name
,nickname
,
preferred_username
,profile
,picture
,website
,gender
,birthdate
,zoneinfo
,locale
, and updated_at
claims.
The email
scope requests access to the email
and email_verified
claims. The process is that
the RP requests specific scopes during the authentication request. If the OP Privacy Policy
allows it and the authenticating user consents to it, the related claims are returned to the
RP (either in the ID Token or as a UserInfo response).
The list of the supported claims will vary depending on the OP you are using, but you can expect the Standard Claims to be largely supported.
Mapping claims to user properties
editThe goal of claims mapping is to configure Elasticsearch in such a way as to be able to map the values of specified returned claims to one of the user properties that are supported by Elasticsearch. These user properties are then utilized to identify the user in the Kibana UI or the audit logs, and can also be used to create role mapping rules.
The recommended steps for configuring OpenID Claims mapping are as follows:
- Consult your OP configuration to see what claims it might support. Note that the list provided in the OP’s metadata or in the configuration page of the OP is a list of potentially supported claims. However, for privacy reasons it might not be a complete one, or not all supported claims will be available for all authenticated users.
-
Read through the list of user properties that Elasticsearch
supports, and decide which of them are useful to you, and can be provided by
your OP in the form of claims. At a minimum, the
principal
user property is required. -
Configure your OP to "release" those claims to your Elastic Stack Relying party. This process greatly varies by provider. You can use a static configuration while others will support that the RP requests the scopes that correspond to the claims to be "released" on authentication time. See
rp.requested_scopes
for details about how to configure the scopes to request. To ensure interoperability and minimize the errors, you should only request scopes that the OP supports, and which you intend to map to Elasticsearch user properties.NOTE: You can only map claims with values that are strings, numbers, boolean values or an array of the aforementioned.
-
Configure the OpenID Connect realm in Elasticsearch to associate the Elasticsearch user properties (see the listing below), to the name of the claims that your OP will release. In the example above, we have configured the
principal
andgroups
user properties as follows:-
claims.principal: sub
: This instructs Elasticsearch to look for the OpenID Connect claim namedsub
in the ID Token that the OP issued for the user ( or in the UserInfo response ) and assign the value of this claim to theprincipal
user property.sub
is a commonly used claim for the principal property as it is an identifier of the user in the OP and it is also a required claim of the ID Token, thus offering guarantees that it will be available. It is, however, only used as an example here, the OP may provide another claim that is a better fit for your needs. -
claims.groups: "http://example.info/claims/groups"
: Similarly, this instructs Elasticsearch to look for the claim with the namehttp://example.info/claims/groups
(note that this is a URI - an identifier, treated as a string and not a URL pointing to a location that will be retrieved) either in the ID Token or in the UserInfo response, and map the value(s) of it to the user propertygroups
in Elasticsearch. There is no standard claim in the specification that is used for expressing roles or group memberships of the authenticated user in the OP, so the name of the claim that should be mapped here, will vary greatly between providers. Consult your OP documentation for more details.
-
Elasticsearch user properties
editThe Elasticsearch OpenID Connect realm can be configured to map OpenID Connect claims to the following properties on the authenticated user:
- principal
-
(Required)
This is the username that will be applied to a user that authenticates
against this realm.
The
principal
appears in places such as the Elasticsearch audit logs.
If the principal property fails to be mapped from a claim, the authentication fails.
- groups
-
(Recommended)
If you wish to use your OP’s concept of groups or roles as the basis for a
user’s Elasticsearch privileges, you should map them with this property.
The
groups
are passed directly to your role mapping rules. - name
- (Optional) The user’s full name.
- (Optional) The user’s email address.
- dn
- (Optional) The user’s X.500 Distinguished Name.
Extracting partial values from OpenID Connect claims
editThere are some occasions where the value of a claim may contain more information
than you wish to use within Elasticsearch. A common example of this is one where the
OP works exclusively with email addresses, but you would like the user’s
principal
to use the local-name part of the email address.
For example if their email address was james.wong@staff.example.com
, then you
would like their principal to simply be james.wong
.
This can be achieved using the claim_patterns
setting in the Elasticsearch
realm, as demonstrated in the realm configuration below:
xpack.security.authc.realms.oidc.oidc1: order: 2 rp.client_id: "the_client_id" rp.response_type: code rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback" op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize" op.token_endpoint: "https://op.example.org/oauth2/v1/token" op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo" op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout" op.issuer: "https://op.example.org" op.jwkset_path: oidc/jwkset.json claims.principal: email_verified claim_patterns.principal: "^([^@]+)@staff\\.example\\.com$"
In this case, the user’s principal
is mapped from the email_verified
claim, but a
regular expression is applied to the value before it is assigned to the user.
If the regular expression matches, then the result of the first group is used as the
effective value. If the regular expression does not match then the claim
mapping fails.
In this example, the email address must belong to the staff.example.com
domain,
and then the local-part (anything before the @
) is used as the principal.
Any users who try to login using a different email domain will fail because the
regular expression will not match against their email address, and thus their
principal user property - which is mandatory - will not be populated.
Small mistakes in these regular expressions can have significant
security consequences. For example, if we accidentally left off the trailing
$
from the example above, then we would match any email address where the
domain starts with staff.example.com
, and this would accept an email
address such as admin@staff.example.com.attacker.net
. It is important that
you make sure your regular expressions are as precise as possible so that
you do not inadvertently open an avenue for user impersonation attacks.
Third party initiated single sign-on
editThe Open ID Connect realm in Elasticsearch supports 3rd party initiated login as described in the relevant specification.
This allows the OP itself or another, third party other than the RP, to initiate the authentication process while requesting the OP to be used for the authentication. Please note that the Elastic Stack RP should already be configured for this OP, in order for this process to succeed.
OpenID Connect Logout
editThe OpenID Connect realm in Elasticsearch supports RP-Initiated Logout Functionality as described in the relevant part of the specification
In this process, the OpenID Connect RP (the Elastic Stack in this case) will redirect the user’s
browser to predefined URL of the OP after successfully completing a local logout. The OP can then
logout the user also, depending on the configuration, and should finally redirect the user back to the
RP. The op.endsession_endpoint
in the realm configuration determines the URL in the OP that the browser
will be redirected to. The rp.post_logout_redirect_uri
setting determines the URL to redirect
the user back to after the OP logs them out.
When configuring rp.post_logout_redirect_uri
, care should be taken to not point this to a URL that
will trigger re-authentication of the user. For instance, when using OpenID Connect to support
single sign-on to Kibana, this could be set to ${kibana-url}/logged_out
, which will show a user-
friendly message to the user.
OpenID Connect Realm SSL Configuration
editOpenID Connect depends on TLS to provide security properties such as encryption in transit and endpoint authentication. The RP
is required to establish back-channel communication with the OP in order to exchange the code for an ID Token during the
Authorization code grant flow and in order to get additional user information from the UserInfo endpoint. Furthermore, if
you configure op.jwks_path
as a URL, Elasticsearch will need to get the OP’s signing keys from the file hosted there. As such, it is
important that Elasticsearch can validate and trust the server certificate that the OP uses for TLS. Since the system truststore is
used for the client context of outgoing https connections, if your OP is using a certificate from a trusted CA, no additional
configuration is needed.
However, if the issuer of your OP’s certificate is not trusted by the JVM on which Elasticsearch is running (e.g it uses a organization CA), then you must configure Elasticsearch to trust that CA. Assuming that you have the CA certificate that has signed the certificate that the OP uses for TLS stored in the /oidc/company-ca.pem` file stored in the configuration directory of Elasticsearch, you need to set the following property in the realm configuration:
xpack.security.authc.realms.oidc.oidc1: order: 1 ... ssl.certificate_authorities: ["/oidc/company-ca.pem"]
On this page
- Enable TLS for HTTP
- Enable the token service
- Create an OpenID Connect realm
- Claims mapping
- Claims and scopes
- Mapping claims to user properties
- Elasticsearch user properties
- Extracting partial values from OpenID Connect claims
- Third party initiated single sign-on
- OpenID Connect Logout
- OpenID Connect Realm SSL Configuration