Secure your clusters with SAML

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

The SAML credentials are valid against the deployment, not the ECE platform. You can configure role-based access control for the platform separately.

Before you begin

Elastic Cloud Enterprise supports SAML with Elastic Stack version 6.4 and later.

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:

Configure your 7.x cluster to use SAML

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.

  1. Create or use an existing deployment that includes a Kibana instance version 6.4 or later.
  2. Copy the Kibana endpoint URL.
  3. 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/v1/saml"
                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.

    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. 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 groups or roles. The values for both attributes.principal and attributes.groups depend 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 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:9243/ including the slash at the end.

  4. 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:

    POST /_xpack/security/role_mapping/CLOUD_SAML_TO_KIBANAUSER 
    {
       "enabled": true,
        "roles": [ "kibana_user" ], 
        "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.

  5. 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 /_xpack/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.

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

    • If you are using a Kibana instance of version 7.3 or later.

      xpack.security.authc.providers: [saml]
      server.xsrf.whitelist: [/api/security/v1/saml]
      xpack.security.authc.saml.realm: saml-realm-name 

      The name of the SAML realm that you have configured above, 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 by setting xpack.security.authc.providers: [saml, basic] in the configuration of Kibana.

    • If you are using a Kibana instance of version 7.2 or earlier.

      xpack.security.authProviders: [saml]
      server.xsrf.whitelist: [/api/security/v1/saml]
      xpack.security.public:
        protocol: https
        hostname: d1a45bf330b74c248d7cc2e0ead8e159.192.168.44.10.ip.es.io 
        port: 9243

      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 basic authProvider by setting xpack.security.authProviders: [saml, basic] in the configuration of Kibana.

  7. Optional: If you have an App Search deployment, you can set it to also use SAML single sign-on authentication. Configure your App Search user settings with the following parameters:

    app_search.auth.source: elasticsearch-saml
    app_search.auth.name: saml-realm-name 

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

  8. 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 configuration using the advanced configuration editor to use the bundle you prepared in the previous step. You need to modify the user_bundles JSON attribute similar to the following example snippet:

      {
        "cluster_name": "REPLACE_WITH_YOUR_CLUSTER_NAME",
        "plan": {
      
          ...
      
          "elasticsearch": {
            "version": "6.4.1",
            "user_bundles": [
              {
                "name": "saml-metadata",
                "url": "https://www.MYURL.com/saml-metadata.zip",
                "elasticsearch_version": "6.4.1"
              }
            ]
          }
        }

      The URLs that point to the ZIP file containing the bundle must be accessible to the deployment. 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.

  9. Use the Kibana endpoint URL to log in.

Configure your 6.x cluster to use SAML

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.

Sign Outgoing SAML Message

If configured, Elastic Stack will sign outgoing SAML messages.

As a prerequisite, you need to generate a signing key and a self-signed certificate. You need to share this certificate with your SAML Identity Provider so that it can verify the received messages. The key needs to be unencrypted. The exact procedure is system dependent, you can use for example openssl

openssl req -new -x509 -days 3650 -nodes -sha256 -out saml-sign.crt -keyout saml-sign.key

Place the files under saml folder and add them to the existing SAML bundle, or create a new one as described above.

In our example, the certificate and the key will be located in the path /app/config/saml/saml-sign.{crt,key}:

$ tree .
.
└── saml
    ├── saml-sign.crt
    └── saml-sign.key

Make sure the bundle is included with your deployment (see above).

Adjust your realm configuration accordingly:

    signing.certificate: /app/config/saml/saml-sign.crt 
    signing.key: /app/config/saml/saml-sign.key 

The path to the SAML signing certificate that was uploaded.

The path to the SAML signing key that was uploaded.

When configured with a signing key and certificate, Elastic Stack will sign all outgoing messages (SAML Authentication Requests, SAML Logout Requests, SAML Logout Responses) by default. This behavior can be altered by configuring signing.saml_messages appropriately with the comma separated list of messages to sign. Supported values are AuthnRequest, LogoutRequest and LogoutResponse and the default value is *.

For example:

xpack:
  security:
    authc:
      realms:
        saml-realm-name:
          order: 2
          ...
          signing.saml_messages: AuthnRequest 
          ...

This configuration ensures that only SAML Authentication Requests will be sent signed to the Identity Provider.

Optional Settings

Following optional realm settings are supported:

  • force_authn Specifies whether to set the ForceAuthn attribute when requesting that the IdP authenticate the current user. If set to true, the IdP is required to verify the user’s identity, irrespective of any existing sessions they might have. Defaults to false.
  • idp.use_single_logout Indicates whether to utilise the Identity Provider’s <SingleLogoutService> (if one exists in the IdP metadata file). Defaults to true.

After completing these steps, you can log into Kibana by authenticating against your SAML IdP. If you encounter any issues with the configuration, please take a look at our SAML troubleshooting page which contains information about common issues and suggestions for their resolution.