These steps show how you can secure your Elasticsearch clusters and Kibana instances in a deployment by using a Security Assertion Markup Language (SAML) identity provider (IdP) for cross-domain, single sign-on authentication.
The steps in this section require an understanding of SAML, specifically the SAML 2.0 Web Browser SSO Profile. To learn more about SAML, see:
- Our blog post on how to enable SAML authentication in Kibana and Elasticsearch.
- Our documentation on configuring Elasticsearch for SAML authentication, especially the details on roles and attribute mappings.
You must edit your cluster configuration, sometimes also referred to as the deployment plan, to point to the SAML IdP before you can complete the configuration in Kibana.
- Create or use an existing deployment that includes a Kibana instance version 6.4 or later.
- Copy the Kibana endpoint URL.
Update your Elasticsearch user settings for the
samlrealm and specify your IdP provider configuration:
xpack: security: authc: realms: saml: cloud-saml: order: 2 attributes.principal: "nameid:persistent" attributes.groups: "groups" idp.metadata.path: "<check with your identity provider>" idp.entity_id: "<check with your identity provider>" sp.entity_id: "KIBANA_ENDPOINT_URL/" sp.acs: "KIBANA_ENDPOINT_URL/api/security/v1/saml" sp.logout: "KIBANA_ENDPOINT_URL/logout"
Specifies the authentication realm service.
You must use the SAML realm name
Defines the SAML attribute that is going to be mapped to the principal (username) of the authenticated user in Kibana. In this example,
urn:oasis:names:tc:SAML:2.0:nameid-format:persistentformat from the Subject of the SAML Assertion. See the attribute mapping documentation for details and available options.
Defines the SAML attribute used for role mapping when configured in Kibana. Common choices are
roles. The values for both
attributes.groupsdepend on the IdP provider, so be sure to review their documentation. See the attribute mapping documentation for details and available options.
The file path or the HTTPS URL where your IdP metadata is available, such as
https://idpurl.com/sso/saml/metadata. If you configure a URL you need to make ensure that your Elasticsearch cluster can access it.
The SAML EntityID of your IdP. This can be read from the configuration page of the IdP, or its SAML metadata, such as
KIBANA_ENDPOINT_URLwith the one noted in the previous step, such as
sp.entity_id: https://eddac6b924f5450c91e6ecc6d247b514.us-east-1.aws.found.io:9243/including the slash at the end.
By default, users authenticating via SAML have no roles assigned to them. For example, if you want all your users authenticating with SAML to get access to Kibana, issue the following request to Elasticsearch:
Alternatively, if you want the users that belong to the group
elasticadminsin your identity provider to be assigned the
superuserrole in your Elasticsearch cluster, issue the following request to Elasticsearch:
The mapping name
The Elastic Stack role to map to
A rule specifying the SAML role to map from
realm.namecan only be
In order to use the field
groupsin the mapping rule, you need to have mapped the SAML Attribute that conveys the group membership to
attributes.groupsin the previous step.
Update Kibana in the user settings configuration to use SAML as the authentication provider:
The hostname from your Kibana endpoint URL
This configuration disables all other realms and only allows users to authenticate with SAML. If you wish to allow your native realm users to authenticate, you need to also enable the
xpack.security.authProviders: [saml, basic]in the configuration of Kibana. You can then access the Kibana login screen at
Optional: If your Identity Provider doesn’t publish its SAML metadata at an http URL, or if your Elasticsearch cluster cannot reach that URL, you can upload the SAML metadata as a file.
Prepare a ZIP file with a custom bundle that contains your Identity Provider’s metadata (
metadata.xml) inside of a
This bundle allows all Elasticsearch containers to access the metadata file.
Update your Elasticsearch cluster on the deployments page to use the bundle you prepared in the previous step.
Custom bundles are unzipped under the path
BUNDLE_DIRECTORY_STRUCTUREis the directory structure in the ZIP file. Make sure to save the file location where custom bundles get unzipped, as you will need it in the next step.
In our example, the SAML metadata file will be located in the path
$ tree . . └── saml └── metadata.xml
samlrealm configuration accordingly:
For 6.x deployments the configuration is slightly different. For step 3, you must specify the realm name, then define the realm
type using the following example:
xpack: security: authc: realms: cloud-saml: type: saml order: 2
All of the other steps are the same.