Secure your clusters with SAML

These steps show how you can secure your Elasticsearch clusters, Kibana, and Enterprise Search instances in a deployment by using a Security Assertion Markup Language (SAML) identity provider (IdP) for cross-domain, single sign-on authentication.

Configure your 8.0 or above cluster to use SAML

edit

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. If you are using machine learning or a deployment with hot-warm architecture, you must include this SAML IdP configuration in the user settings section for each node type.

Create or use an existing deployment that includes a Kibana instance.
Copy the Kibana endpoint URL.

Update your Elasticsearch user settings for the saml realm and specify your IdP provider configuration:

xpack:
  security:
    authc:
      realms:
        saml: 
          saml-realm-name: 
            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/saml/callback"
            sp.logout: "KIBANA_ENDPOINT_URL/logout"

	Specifies the authentication realm service.
	Defines the SAML realm name. The SAML realm name can only contain alphanumeric characters, underscores, and hyphens.
	The order of the SAML realm in your authentication chain. Allowed values are between `2` and `100`. Set to `2` unless you plan on configuring multiple SSO realms for this cluster.
	Defines the SAML attribute that is going to be mapped to the principal (username) of the authenticated user in Kibana. In this non-normative example, `nameid:persistent` maps the `NameID` with the `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` format from the Subject of the SAML Assertion. You can use any SAML attribute that carries the necessary value for your use case in this setting, such as `uid` or `mail`. Refer to the attribute mapping documentation for details and available options.
	Defines the SAML attribute used for role mapping when configured in Kibana. Common choices are `groups` or `roles`. The values for both `attributes.principal` and `attributes.groups` depend on the IdP provider, so be sure to review their documentation. Refer to 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 `https://idpurl.com/entity_id`.
	Replace `KIBANA_ENDPOINT_URL` with the one noted in the previous step, such as `sp.entity_id: https://eddac6b924f5450c91e6ecc6d247b514.us-east-1.aws.found.io:443/` including the slash at the end.

By default, users authenticating through 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:

POST /_security/role_mapping/CLOUD_SAML_TO_KIBANA_ADMIN 
{
   "enabled": true,
    "roles": [ "kibana_admin" ], 
    "rules": { 
        "field": { "realm.name": "saml-realm-name" } 
    },
    "metadata": { "version": 1 }
}

	The mapping name.
	The Elastic Stack role to map to.
	A rule specifying the SAML role to map from.
	`realm.name` can be any string containing only alphanumeric characters, underscores, and hyphens.

Alternatively, if you want the users that belong to the group elasticadmins in your identity provider to be assigned the superuser role in your Elasticsearch cluster, issue the following request to Elasticsearch:

POST /_security/role_mapping/CLOUD_SAML_ELASTICADMIN_TO_SUPERUSER 
{
   "enabled": true,
    "roles": [ "superuser" ], 
    "rules": { "all" : [ 
        { "field": { "realm.name": "saml-realm-name" } }, 
        { "field": { "groups": "elasticadmins" } }
    ]},
    "metadata": { "version": 1 }
}

	The mapping name.
	The Elastic Stack role to map to.
	A rule specifying the SAML role to map from.
	`realm.name` can be any string containing only alphanumeric characters, underscores, and hyphens.

In order to use the field groups in the mapping rule, you need to have mapped the SAML Attribute that conveys the group membership to attributes.groups in the previous step.

Update Kibana in the user settings configuration to use SAML as the authentication provider:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: saml-realm-name

The name of the SAML realm that you have configured earlier, for instance saml-realm-name. The SAML realm name can only contain alphanumeric characters, underscores, and hyphens.

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 basic provider like this:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: saml-realm-name
    description: "Log in with my SAML" 
  basic.basic1:
    order: 1

This arbitrary string defines how SAML login is titled in the Login Selector UI that is shown when you enable multiple authentication providers in Kibana. You can also configure the optional icon and hint settings for any authentication provider.

+ . Optional: Generate SAML metadata for the Service Provider.

+ The SAML 2.0 specification provides a mechanism for Service Providers to describe their capabilities and configuration using a metadata file. If your SAML Identity Provider requires or allows you to configure it to trust the Elastic Stack Service Provider through the use of a metadata file, you can generate the SAML metadata by issuing the following request to Elasticsearch:

GET /_security/saml/metadata/realm_name

+ <1> The name of the SAML realm in Elasticsearch.

+ You can generate the SAML metadata by issuing the API request to Elasticsearch and storing metadata as an XML file using tools like jq.

+ The following command, for example, generates the metadata for the SAML realm saml1 and saves it to metadata.xml file:

curl -X GET -H "Content-Type: application/json" -u user_name:password https://<elasticsearch_endpoint>:443/_security/saml/metadata/saml1 
|jq -r '.[]' > metadata.xml

+ <1> The elasticsearch endpoint for the given deployment where the saml1 realm is configured.

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.
1. Prepare a ZIP file with a custom bundle that contains your Identity Provider’s metadata (metadata.xml) inside of a saml folder.
  
  This bundle allows all Elasticsearch containers to access the metadata file.
2. 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 /app/config/BUNDLE_DIRECTORY_STRUCTURE, where BUNDLE_DIRECTORY_STRUCTURE is 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 /app/config/saml/metadata.xml:
```
$ tree .
.
└── saml
      └── metadata.xml
```
3. Adjust your saml realm configuration accordingly:
```
    idp.metadata.path: /app/config/saml/metadata.xml 
```
  The path to the SAML metadata file that was uploaded.
Use the Kibana endpoint URL to log in.

Configure your 7.x cluster to use SAML

edit

For 7.x deployments, the instructions are similar to those for 8.x, but your Elasticsearch request should use POST /_security/role_mapping/CLOUD_SAML_TO_KIBANA_ADMIN (for Step 4) or POST /_security/role_mapping/CLOUD_SAML_ELASTICADMIN_TO_SUPERUSER (for Step 5).

All of the other steps are the same.

« Secure your settings Sign outgoing SAML messages »