- X-Pack Reference for 6.0-6.2 and 5.x:
- Introduction
- Setting Up X-Pack
- Breaking Changes
- X-Pack APIs
- Graphing Connections in Your Data
- Profiling your Queries and Aggregations
- Reporting from Kibana
- Securing the Elastic Stack
- Getting Started with Security
- How Security Works
- Setting Up User Authentication
- Configuring SAML Single-Sign-On on the Elastic Stack
- Configuring Role-based Access Control
- Auditing Security Events
- Encrypting Communications
- Restricting Connections with IP Filtering
- Cross Cluster Search, Tribe, Clients and Integrations
- Reference
- Monitoring the Elastic Stack
- Alerting on Cluster and Index Events
- Machine Learning in the Elastic Stack
- Troubleshooting
- Getting Help
- X-Pack security
- Can’t log in after upgrading to 6.2.4
- 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
- Internal Server Error in Kibana
- Setup-passwords command fails due to connection failure
- X-Pack Watcher
- X-Pack monitoring
- X-Pack machine learning
- Limitations
- License Management
- Release Notes
WARNING: Version 6.2 of the Elastic Stack has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Configuring Role Mappings
editConfiguring Role Mappings
editWhen a user authenticates using SAML, they are identified to the Elastic Stack, but this does not automatically grant them access to perform any actions or access any data.
Your SAML users cannot do anything until they are mapped to X-Pack Security roles. This mapping is performed through the role-mapping API
This is an example of a simple role mapping that grants the kibana_user
role
to any user who authenticates against the saml1
realm:
PUT /_xpack/security/role_mapping/saml-kibana { "roles": [ "kibana_user" ], "enabled": true, "rules": { "field": { "realm.name": "saml1" } } }
The attributes that are mapped via the realm configuration are used to process role mapping rules, and these rules determine which roles a user is granted.
The user fields that are provided to the role mapping are derived from the SAML attributes as follows:
-
username
: Theprincipal
attribute -
dn
: Thedn
attribute -
groups
: Thegroups
attribute -
metadata
: See User Metadata
For more information, see Mapping Users and Groups to Roles and Role Mapping APIs.
If your IdP has the ability to provide groups or roles to Service Providers,
then you should map this SAML attribute to the attributes.groups
setting in
the Elasticsearch realm, and then make use of it in a role mapping as per the example
below.
This mapping grants the Elasticsearch finance_data
role, to any users who authenticate
via the saml1
realm with the finance-team
group.
PUT /_xpack/security/role_mapping/saml-finance { "roles": [ "finance_data" ], "enabled": true, "rules": { "all": [ { "field": { "realm.name": "saml1" } }, { "field": { "groups": "finance-team" } } ] } }