We'll walk through a basic configuration, creating a new application in Auth0, and configuring the SAML realm in ECE.

<a href="https://www.elastic.co/ece">Elastic Cloud Enterprise (ECE)</a> makes it easy to manage your Elastic Stack deployments, just like role-based access control (RBAC) makes it easy to manage your users. Combining the two can really make an administrator's life much simpler.The intent of this blog post is to provide instructions for configuring a SAML realm for RBAC in ECE environments where Auth0 is used as an identity provider (IdP). We will set up a basic configuration that can be used as a baseline for more advanced configurations tuned for your specific use case. Additional configuration options that are not discussed in this blog post are available in the <a href="https://www.elastic.co/guide/en/cloud-enterprise/current/ece-create-saml-profiles.html">ECE SAML providers documentation</a>, which was used to generate required information discussed in prerequisites.&nbsp;<h2>Prerequisites</h2><ul><li><a href="https://www.elastic.co/ece">Elastic Cloud Enterprise (ECE)</a> version 2.3+ (v2.5 is used for this blog)&nbsp;</li><li>Auth0 account (the free version is used in this blog)</li></ul><h2>Configuration</h2>For the ECE-related portion of SAML configuration, FQDN and port are environment-dependent, while trailing /api/v1/users/auth/saml/_callback in ECE ACS URL and trailing /api/v1/users/auth/_logout in ECE Logout URL are not. For the purposes of this blog, the following configuration was used:<ul><li>ECE URL: <a href="https://ece.elastic.lab:12443">https://ece.elastic.lab:12443</a></li><li>ECE ACS URL: <a href="https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback">https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback</a></li><li>ECE Logout URL: <a href="https://ece.elastic.lab:12443/api/v1/users/auth/_logout">https://ece.elastic.lab:12443/api/v1/users/auth/_logout</a></li><li>ECE service provider entity ID: <a href="https://ece.elastic.lab:12443">https://ece.elastic.lab:12443</a></li><li>Auth0 identity provider entity ID: urn:ece-lab.eu.auth0.com</li><li>Auth0 users:&nbsp;<ul><li>User 1: user1@elastic.lab</li><li>User 2: user2@elastic.lab</li></ul></li></ul><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb1b021f15953e46c/5f44076aba7f910f91e00353/blog-ece-saml-users.png" data-sys-asset-uid="bltb1b021f15953e46c" alt="The Auth0 Users UI"/><h2>Create a new application in Auth0</h2>Before we can configure the SAML realm in ECE, we need to retrieve information about the metadata download URL and identity provider ID from Auth0. This information is specific to the application created in Auth0, so&nbsp;we need to create one for our ECE deployment.&nbsp;Step 1: Navigate to Applications and click on Create Application.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2531cc5a6c34747b/5f4407a4dc23b20fc40274e3/blog-ece-saml-create-application.png" data-sys-asset-uid="blt2531cc5a6c34747b" alt="Navigate to Applications and click on Create Application"/>Step 2: Enter a name for the new application (ECE SAML in this example), select Regular Web Applications, and click Create.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4c5f81f79a51b9b5/5f4407d033bd560fb6d7d776/blog-ece-saml-create-application2.png" data-sys-asset-uid="blt4c5f81f79a51b9b5" alt="Enter a name for the new application, select Regular Web Applications, and click Create"/>Step 3: A new frame will open; click on Settings and scroll down to Application URIs. Enter a value in Allowed Callback URLs that matches the one for your ECE deployment.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt12ff4b62cae9ef9f/5f4407f4374080730caefd31/blog-ece-saml-callback-urls.png" data-sys-asset-uid="blt12ff4b62cae9ef9f" alt="Enter a value in Allowed Callback URLs that matches the one for your ECE deployment"/>Step 4: Navigate to the bottom of the page and click on Show advanced settings, then select Endpoints and copy the SAML Metadata URL from the SAML frame:&nbsp;<div class="video embed-container" style="height: 319.725px;"><img style="width: 100%;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/WzhmgKD5SMG3UgSQPQY7JD.jpg" data-uuid="WzhmgKD5SMG3UgSQPQY7JD" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="0" width="100%"/></div>Step 5: Enable Auth0’s SAML2 addon and configure it. To enable the addon, navigate to Addons and change the switch on the SAML 2 Web App tile:<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5afc6d5a0644b045/5f44081f5010420f8a6a9415/blog-ece-saml-ece-saml.png" data-sys-asset-uid="blt5afc6d5a0644b045" alt="Enable the SAML 2 Web App"/>Step 6: A new window will open where we need to configure the addon. We first need to add an application callback URL, which in our case is: <a href="https://ece.elastic.lab/api/v1/users/auth/saml/_callback">https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback</a>.&nbsp;Then we need to copy the contents of the Settings frame to a text editor, modify it, and copy it back. For the purposes of this blog&nbsp;we are only changing:<ul><li>audience: The ECE Service Provider SAML Entity ID&nbsp;</li><li>recipient: The&nbsp; ECE Service Provider SAML Assertion Consumer URL</li><li>destination: The&nbsp; ECE Service Provider SAML Assertion Consumer URL</li><li>logout callback: The&nbsp; ECE Service Provider SAML Single Logout URL</li><li>nameIdentifierFormat: The NameID format that Auth0 will use, we select persistent here</li><li>binding: The binding that Auth0 will use for Logout Request messages</li><li>signResponse: Setting this to true instructs Auth0 to sign the whole SAML Response instead of just the SAML Assertion, which is a security best practice.</li></ul>The configuration should match the Elasticsearch requirements as explained in the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/saml-guide-idp.html">IdP documentation</a>. Here is the example configuration we’ll use:&nbsp;<pre class="prettyprint">{ "audience": "https://ece.elastic.lab:12443", "recipient": "https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback", "destination": "https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback", "signResponse": true, "typedAttributes": true, "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent", "logout": { "callback": "https://ece.elastic.lab:12443/api/v1/users/auth/_logout", "slo_enabled": true }, "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" } </pre>Once the settings configuration is updated we copy it back in the settings frame in the addon configuration page and click on Enable.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt09a8a07237e72509/5f44084433bd560fb6d7d77a/blog-ece-saml-enable.png" data-sys-asset-uid="blt09a8a07237e72509" alt="The addon configuration page" style="background-color: initial;"/>This concludes the Auth0 configuration and the majority of the heavy lifting is done. The only remaining thing is to configure a&nbsp;SAML provider in ECE, which is pretty straightforward.&nbsp;<h2>Configuring the SAML realm in ECE</h2>Step 1: To configure the SAML realm for RBAC in ECE, you will first open the Users UI in the main ECE UI, then select Authentication Providers and click on Add provider. A dropdown window will appear where we select SAML:<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt78e7ded3b733d24c/5f4408893f3ea57f976c43b8/blog-ece-saml-authentication-providers.png" data-sys-asset-uid="blt78e7ded3b733d24c" alt="Authentication providers"/>Step 2: A new page will open where we need to enter information. We will first add the profile name for the new provider which in this example we call “ECE-SAML.” After that we enter the following information:<ul><li>ECE SAML service provider Assertion Consumer Service URL</li><li>ECE SAML service provider Logout URL</li><li>SAML identity provider entity ID</li><li>ECE SAML service provider entity ID</li><li>SAML identity provider metadata URL</li></ul>We discussed those in prerequisites, so we can just copy them in:&nbsp;<ul><li>Profile name: ECE-SAML</li><li>ECE ACS URL: <a href="https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback">https://ece.elastic.lab:12443/api/v1/users/auth/saml/_callback</a></li><li>ECE Logout URL: <a href="https://ece.elastic.lab:12443/api/v1/users/auth/_logout">https://ece.elastic.lab:12443/api/v1/users/auth/_logout</a></li><li>ECE service provider entity ID: <a href="https://ece.elastic.lab:12443">https://ece.elastic.lab:12443</a></li><li>Identity provider entity ID: urn:ece-lab.eu.auth0.com</li></ul><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc2c9fed21c27e828/5f4408c4ba7f910f91e00357/blog-ece-saml-add-saml-provider.png" data-sys-asset-uid="bltc2c9fed21c27e828" alt="Add SAML provider"/>Step 3: Once the basic information is added we need to configure the attribute mapping between SAML attributes and ECE user properties so that it matches the configuration of the IdP. We left this configuration to use the default values when we were configuring Auth0:&nbsp;<pre class="prettyprint"> "mappings": { "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "groups": "http://schemas.xmlsoap.org/claims/Group" }, </pre>Based on this, we will use:&nbsp;<ul><li>Principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"</li><li>Groups: "http://schemas.xmlsoap.org/claims/Group"</li></ul>To learn more about user attributes, see the <a href="https://www.elastic.co/guide/en/cloud-enterprise/2.5/ece-configure-rbac.html#ece-saml-attributes">ECE RBAC documentation</a>.&nbsp;<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt57fa2746205ad824/5f4408e4dc23b20fc40274eb/blog-ece-saml-attribute-mapping.png" data-sys-asset-uid="blt57fa2746205ad824" alt="Attribute mapping"/>Step 4: The last remaining configuration is role mappings for SAML users. ECE has four different levels of access:&nbsp;<ul><li>Platform admin: Same access as the admin system user.</li><li>Platform viewer: Same access as the read-only system user, which includes being able to view secret and sensitive settings.</li><li>Deployment manager: Can create and manage non-system deployments, specify keystore security settings, and establish cross-cluster remote relationships. Can also reset the elastic password.</li><li>Deployment viewer: Can view non-system deployments, including their activity. Can prepare the diagnostic bundle, inspect the files, and download the bundle as a ZIP file.&nbsp;</li></ul>We will configure all SAML users as Deployment viewer (default role) and then add two additional mappings for user1@elastic.lab - Platform admin and user2@elastic.lab - Platform viewer:<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltcb1217367dadb6a1/5f4408ffdc23b20fc40274ef/blog-ece-saml-role-mappings.png" data-sys-asset-uid="bltcb1217367dadb6a1" alt="Role mappings"/>Adding a role mapping:&nbsp;<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9d950e86475c3c14/5f440a3e33bd560fb6d7d782/blog-ece-saml-add-role-mapping.png" data-sys-asset-uid="blt9d950e86475c3c14" alt="Add a role mapping" style="display: block;margin: auto;width: 300;" width="300"/>Once this is done, all that we need to do is click on Create profile and configuration will take place. This will take some time, as it is effectively changing the configuration of the security-cluster system-owned deployment.&nbsp;<h2>Try it out</h2>After the configuration is done, we can log out of the ECE UI. The login screen will change, and instead of a username and password form, there will be a new Log in with ECE-SAML button.&nbsp;After clicking it, we will be redirected to the Auth0 login page and if we enter correct credentials we will be logged into ECE with SAML credentials.<div class="video embed-container" style="height: 319.725px;"><img style="width: 100%;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/x3TrhEJU7EMZnTvTNkvrw9.jpg" data-uuid="x3TrhEJU7EMZnTvTNkvrw9" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="0" width="100%"/></div><h2>Troubleshooting&nbsp;</h2>SAML authentication for ECE consists of many different components, so a good troubleshooting plan enables us to resolve issues quickly. In ECE, SAML authentication is handled by the security cluster that ships logs into the logging and metrics cluster, where they can be reviewed. By default, level of SAML logging is set to info, and sometimes we will need to increase the logging level, which can be done by configuring the following cluster setting on the security cluster:&nbsp;<pre class="prettyprint">PUT /_cluster/settings { "transient": { "logger.org.elasticsearch.xpack.security.authc.saml": "trace" } } </pre>Please note that this will provide a large number of logs, which can lead to disk space problems, so once a couple of SAML events are captured, logging should be reverted back to normal. Once you have some logs to look at, the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/trb-security-saml.html">common SAML issues documentation page</a> might come in handy.<h2>Final thoughts</h2>In this blog we discussed how to configure SAML for ECE RBAC functionality in order to log in to your ECE platform using an external identity provider. If you would like, you can also add SAML authentication to your ECE deployments. More information on how to configure SAML authentication for deployment can be found on this <a href="https://www.elastic.co/guide/en/cloud-enterprise/current/ece-securing-clusters-SAML.html">documentation page</a>.

ece-blog-banner.png

ece-blog-thumb.png

Configuring a SAML realm for role-based access control in ECE

Find out how to configure Elasticsearch SAML authentication in environments using Microsoft Active Directory Federation Services (ADFS).

This blog post provides instructions for configuration of Elasticsearch SAML authentication in environments where Microsoft Active Directory Federation Services (ADFS) is used as an identity provider (IdP) for an Elasticsearch SAML realm. The main purpose is to establish a working solution, which can be taken as a baseline for more advanced configurations that depend on use case–specific requirements. Additional configuration options that are not discussed in this blog post are available in <a href="/guide/en/elasticsearch/reference/current/configuring-saml-realm.html">Elasticsearch SAML guide</a>, <a href="/guide/en/cloud/current/ec-securing-clusters-SAML.html">Elasticsearch Service SAML documentation</a>, and <a href="/guide/en/cloud-enterprise/current/ece-securing-clusters-SAML.html">Elastic Cloud Enterprise SAML documentation</a>.
<h3>Prerequisites:</h3>
<ul>
 <li>Elasticsearch cluster with at least 1 node and Kibana</li>
 <li>Windows Server 2016, 2019, 2022</li>
 <li>Active Directory Domain Services (AD DS)</li>
 <li>Active Directory Federation Services (ADFS)</li>
</ul>
For the purposes of this blog, the following configuration was used:
<ul>
 <li>Kibana URL: https://kibana.example.com/li>
 <li>ADFS FQDN: adfs.saml.lab</li>
 <li>Domain: saml.lab</li>
 <li>AD groups: kibana_user, superuser</li>
 <li>User 1 (member of ad_kibana_users_group group): es_user1@saml.lab</li>
 <li>User 2 (member of ad_superusers_group group): es_user2@saml.lab</li>
</ul>
<h4><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltfba8626cff944571/5dc0807ba85dd3382954ef74/saml-adfs-users-1-blog.jpg" data-sys-asset-uid="bltfba8626cff944571" alt="AD users and computers" /></h4>
<h3>Configuring the SAML realm in elasticsearch.yml</h3>
To configure the SAML realm, you will open Elasticsearch.yml file in an editor, add the following configuration on all the ES nodes, and restart them. If Elasticsearch Service is used, you would update Elasticsearch node user overrides configuration as per <a href="/guide/en/cloud/current/ec-securing-clusters-SAML.html#ec-securing-clusters-SAML">this documentation page</a>.<pre class="prettyprint">xpack.security.authc.realms.saml.saml-adfs: order: 2 idp.metadata.path: metadata/FederationMetadata.xml idp.entity_id: "https://adfs.saml.lab/adfs/services/trust" sp.entity_id: "https://kibana.example.com/" sp.acs: "https://kibana.example.com/api/security/saml/callback" sp.logout: "https://kibana.example.com/logout" attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" attributes.groups: "http://schemas.xmlsoap.org/claims/Group" nameid_format: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"</pre>
Configurations specifics:
idp.metadata.path references the location where the SAML metadata of the IdP (FederationMetadata.xml in this example) is accessible. There are two ways of providing the SAML metadata of the IdP to Elasticsearch: one by uploading the metadata file to all the nodes (in Elasticsearch Service you use a bundle as described <a href="/guide/en/cloud/current/ec-securing-clusters-SAML.html">here</a>) into a folder that Elasticsearch process can access, or by specifying an https URL where metadata is accessible.
idp.entity_id is the EntityID of the SAML IIdP, as it is also specified in the IdP metadata file.
Sp.entity_id is the SAML EntityID, a string that will identify this service provider (SP). Entity IDs are matched as strings and not as canonicalized URLs, so things like trailing slashes and port numbers matter. Note that the SP EntityID is only an identifier and will never need to be resolved or accessed as a URL.
sp.acs: The Assertion Consumer Service (ACS) endpoint is the URL within Kibana that accepts authentication messages. This ACS endpoint supports the SAML HTTP-POST binding only. It must be a URL that is accessible from the web browser of the user who is attempting to log in to Kibana; it does not need to be directly accessible by Elasticsearch or the IdP.
Sp.logout must be configured as the URL in Kibana that accepts logout messages. Please note that configuring SAML logging will require certificate configuration to sign SAML messages. Configuring certificates and message signing is out of scope for this blog post, but detailed configuration is available on <a href="/guide/en/elasticsearch/reference/6.7/saml-guide-authentication.html#saml-enc-sign">this documentation page</a>.
Attributes.principaldefines which attribute from the attribute statement of the SAML response that the IdP sends, and should be mapped and used as the user principal in Elasticsearch and Kibana. For the purpose of this blog post, you will describe how UPN or the SAML NameID with persistent format can be mapped. More information on attribute mapping for the SAML realm is available <a href="/guide/en/elasticsearch/reference/current/saml-guide-authentication.html#saml-attribute-mapping">here</a>.
attributes.groups defines which attribute from the attribute atatement of the SAML response that the IdP sends, and should be mapped as the groups property of the user in Elasticsearch and Kibana. The mapped values can then be used to assign roles to specific users.
nameid_format defines the NameID format that Elasticsearch will request from ADFS when sending the SAML authentication request at the beginning of the SAML SSO flow. The value is important, because if ADFS is not correctly configured to “release” a NameID with the same format, the authentication will fail. If you don’t plan to use a persistent NameID, you can leave this setting to
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified is the default format that ADFS supports. If you want to use a persistent Name ID, then set the value to urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and complete the extra configuration step in "Step 2: Configure ADFS claims" below.
<h3>Configuring the SAML realm in kibana.yml</h3>
 In Kibana we need to configure the login selector and add the newly configured SAML realm. To ensure you can login with normal users in case there is an issue with SAML, we also add support for the basic authentication provider to the config added to kibana.yml. &nbsp; If Elasticsearch Service is used, we would update Kibana nodes user overrides configuration as per <a href="https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html#ec-securing-clusters-SAML">this documentation page</a>..<pre class="prettyprint"> xpack.security.authc.providers: saml.saml1: order: 0 realm: saml-adfs description: "Log in with my SAML ADFS" basic.basic1: order: 1</pre>
<h3>Generate metadata file for use with ADFS</h3>
Please note that this step is optional and not available for deployments running in Elasticsearch Service.
Elasticsearch includes a tool that generates a metadata file based on the configuration specified in the yml configuration file. It will output a metadata.xml file that can be imported into ADFS and will simplify configuration of IDP. Detailed instructions for running elasticsearch-saml-metadata are described on <a href="/guide/en/elasticsearch/reference/current/saml-metadata.html">this documentation page</a>. For this example we used the following syntax and enter required information about the contact details:<pre class="prettyprint">bin/elasticsearch-saml-metadata --realm saml-adfs \ --service-name kibana-access \ --locale en-GB \ --contacts \ --organisation-name "SAML LAB" \ --organisation-url "<a href="http://saml.lab/demo/">http://saml.lab/demo/</a>" </pre>
<h3>Configuring ADFS IdP:</h3>
To prepare ADFS to act as an IdP for Elasticsearch SAML, you need to complete two parts of configuration. In first part you will configure Relying Party Trust, where you configure ADFS to trust our Elasticsearch cluster. This can be done manually or by using the metadata created with the elasticsearch-saml-metadata tool. In the second part you will configure the type of claims (attributes) that ADFS will forward to Elasticsearch.
<h4>Step 1a: Configure the ADFS Relying Party Trust manually:</h4>
<ol>
 <li>In Server Manager click tools and open AD FS Management.</li>
 <li>Expand Trust Relationships, right-click on Relying Party Trust, and select Add Relying Party Trust.</li>
 <li>In the wizard, select Claims aware and click Start.</li>
 <li>
 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc565f05e24467c21/5dc08113a85dd3382954ef80/saml-adfs-add-relying-2-blog.jpg" data-sys-asset-uid="bltc565f05e24467c21" alt="Wizard welcome screen" style="display: block;margin: auto;" />
 </li>
</ol>
<ol start="4">
 <li>Select “Enter data about the relying party manually” and click Next.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2a44d736696c7e2a/5dc081da16de0d360b25e453/saml-adfs-select-data-3-blog.jpg" data-sys-asset-uid="blt2a44d736696c7e2a" alt="Enter data manually option" style="display: block;margin: auto;" /></li>
</ol>
<ol start="5">
 <li>Enter the display name for the claims provider.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt260a76f38f988a05/675a0488ea6bc6ab7818647f/update-1.png" alt="update-1.png" height="auto" /></li>
</ol>
<ol start="6">
 <li>On the Configure Certificate page, skip configuration and click Next.</li>
 <li>On the Configure URL page of wizard, enable support for SAML 2.0 Web SSO protocol and enter the SSO service URL. This is the same value you added above in the sp.acs parameter of Elasticsearch SAML realm configuration: https://kibana.example.com/api/security/saml/callback
 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt91fe7bd0eee8ef16/675b074830b280222adf40b5/update-2.png" alt="update-2.png" height="auto" />
 </li>
</ol>
<ol start="8">
 <li>On the Configure Identifiers step, add the Relying Party Trust identifier, which will be the same string as configured for sp.entity_id in the Elasticsearch SAML realm configuration — in this case that is https://kibana.example.com/.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt04f962b9501538b8/675b07b5a98d6578accd050d/update-3.png" alt="update-3.png" height="auto" /></li>
</ol>
<ol start="9">
 <li>On the next three steps you select defaults, or configure which users can use this Relying Party Trust. Detailed configuration is out of scope for this blog.</li>
</ol>
<h4>Step 1b: Configure the ADFS Relying Party Trust by using metadata:</h4>
<ol>
 <li>In ADFS management expand Trust Relationships, right-click Relying Party Trust and select Add Relying Party Trust.</li>
 <li>In the wizard, select Claims aware and click Start.</li>
 <li>Select the metadata file created and follow the wizard:<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt72f3061e9b1519c3/5dc0833d168dd039dfa5c533/saml-adfs-config-with-metadata-7-blog.gif" data-sys-asset-uid="blt72f3061e9b1519c3" alt="saml-adfs-config-with-metadata-7-blog.gif" /></li>
</ol>
<h4>Step 2: Configure ADFS claims:</h4>
In the second part you will configure what attributes ADFS will send to Elasticsearch as part of SAML authentication process. For the purposes of this blog post, we will configure ADFS to release both an attribute user principal name (UPN) and a NameID. Both of these can be mapped to attributes.principal in the Elasticsearch configuration, so you can select to configure either one of them. You will also configure a claim for Group membership so that you can then map the values in Elasticsearch using attributes.groups.
<ol>
 <li>In the Relying Party Trusts (RPT) frame, right-click the newly created Elasticsearch 7.4.0 RPT and select Edit Claim Issuance Policy.</li>
 <li>Select Add Rule to open Add Rule wizard.</li>
 <li>Select Send LDAP Attributes as Claims and click Next.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4ade089a94ae1c9f/5dc08404f9248a391f9281c4/saml-adfs-select-rule-template-10-blog.jpg" data-sys-asset-uid="blt4ade089a94ae1c9f" alt="Select the rule template" style="display: block;margin: auto;" /></li>
</ol>
<ol start="4">
 <li>Enter a new name for the Claim rule, select Active Directory as the Attribute store, and create a new mapping of LDAP attributes to outgoing claim types. Based on our current configuration, you are mapping User-Principal-Name to UPN (type UPN if it doesn't exist) and Token-Groups - Unqualified names -&nbsp;Group. Click Finish.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltac88a4cd4f10826d/5dc083d5168dd039dfa5c545/saml-adfs-config-rule-9-blog.jpg" data-sys-asset-uid="bltac88a4cd4f10826d" alt="Configure rules" style="display: block;margin: auto;" /></li>
</ol>
<ol start="5">
 <li>If attributes.principal: “nameid:persistent” was configured, you need to add an additional claim rule to transform the UPN attribute to persistent NameID. As before, click the Add Rule to open the wizard, but this time select “Transform an incoming claim” template.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf1ed750d792e76d2/5dc083984290423395c9f3cd/saml-adfs-select-rule-8-blog.jpg" data-sys-asset-uid="bltf1ed750d792e76d2" alt="Select rule template" style="display: block;margin: auto;" /></li>
</ol>
<ol start="6">
 <li>In the next step you configure the transformation of the UPN attribute to Persistent Nameid as per this screenshot and save the newly created rule.<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltade1be81b1a192b6/5dc0843bf9248a391f9281ca/saml-adfs-edit-rule-11-blog.jpg" data-sys-asset-uid="bltade1be81b1a192b6" alt="Edit rule name ID" style="display: block;margin: auto;" /></li>
</ol>
Note, that you don’t necessarily have to use UPN as the incoming claim type, but can select another value if it better suits the configuration.
This concludes configuration of ADFS.
<h3>Configuring SAML role mappings</h3>
When you configured Kibana setting for SAML authentication, you enabled the saml authentication provider, as well as the basic authentication provider by configuring xpack.security.authc.providers: [saml, basic]. This enables us to log in into Kibana even if SAML authentication is currently not working. With both saml and basic provider enabled, you need to navigate to <kibana_url>/login in order to log in to Kibana with local user credentials. For this blog post, you will log in with local elastic user and use Kibana Dev Tools to create role mappings in Elasticsearch, based on the membership of our SAML users in Active Directory groups. The Elasticsearch REST API can be used instead of Kibana Dev Tools as described on <a href="/guide/en/elasticsearch/reference/current/security-api-put-role-mapping.html">this Elasticsearch documentation page</a>. Our ad_kibana_users_group AD group will map to the kibana_user role in Elasticsearch and the ad_superusers_group AD group will map to the superuser role in Elasticsearch.
Superuser mapping:<pre class="prettyprint">POST /_security/role_mapping/saml-superuser { "enabled" : true, "roles" : [ "superuser" ], "rules" : { "all" : [ { "field" : { "realm.name" : "saml-adfs" } }, { "field" : { "groups" : "ad_superusers_group" } } ] }, "metadata" : { } } </pre>
Kibana_user mapping:<pre class="prettyprint">POST /_security/role_mapping/saml-kibana { "enabled" : true, "roles" : [ "kibana_user" ], "rules" : { "all" : [ { "field" : { "realm.name" : "saml-adfs" } }, { "field" : { "groups" : "ad_kibana_users_group" } } ] }, "metadata" : { } } </pre>
<h3>Log in with SAML and enjoy</h3>
If all is correct, you should now be able to log in into Kibana with SAML. After navigating to <a href="https://kibana.saml.lab:5601">https://kibana.saml.lab:5601</a> you are redirected to the ADFS login page that looks like the screenshot below — without the awesome ELK B :) — and after entering credentials you will be logged into Kibana.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8557413fdd4518f7/5dc0846aec08dd3a777183e2/saml-adfs-login-12-blog.gif" data-sys-asset-uid="blt8557413fdd4518f7" alt="Log in to Kibana with SAML" style="display: block;margin: auto;" />
<h3>In case of issues</h3>
SAML authentication has many different components, so a good troubleshooting plan enables us to resolve issues quickly. As a first step, you should review Elasticsearch and ADFS logs. Elasticsearch log location will be based on your Elasticsearch configuration, and ADFS logs are located in the Event Viewer under Application and Services logs:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0f3bd6fd3401f596/5dc084c5b5f194339a9b7fd8/saml-adfs-event-viewer-13-blog.jpg" data-sys-asset-uid="blt0f3bd6fd3401f596" alt="Checking ADFS logs in the Event Viewer" style="display: block;margin: auto;" />
Configuration issues should produce logs describing the issue. If you don’t see any issues in ADFS or Elasticsearch logs, we have a great documentation page that describes <a href="/guide/en/elasticsearch/reference/7.4/trb-security-saml.html">common SAML issues</a>, and you can use it as a reference to see if your issue matches any of the common issues. If you still don’t find anything that matches the issue, you can increase the logging level for SAML events in Elasticsearch, and review the trace logs. To increase the level of SAML logs, you need to configure the following cluster setting:<pre class="prettyprint">PUT /_cluster/settings { "transient": { "logger.org.elasticsearch.xpack.security.authc.saml": "trace" } } </pre>
Please note that this will provide a large number of logs, which can lead to disk space problems on Elasticsearch nodes, so once a couple of SAML events are captured, logging should be reverted back to normal.

saml-adfs-blog-banner.jpg

saml-adfs-blog-thumb.jpg

How to configure Elasticsearch SAML authentication with ADFS

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Rok Orsic

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

제출하면 귀하가 <a href="/kr/legal/elastic-cloud-account-terms" target="_self">Elastic 서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 연락처로 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">선택한 커뮤니케이션</a>을 수신하는 데 동의한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

제출하면 귀하가 Elastic <a href="/kr/legal/serverless-preview-terms" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

제출하면 <a href="/kr/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 서비스 약관</a>에 동의하시게 됩니다. 개인 데이터는 <a href="/kr/legal/privacy-statement">Elastic의 개인정보 취급방침</a>에 따라 처리됩니다.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

제출하면 귀하가 Elastic <a href="/kr/legal/terms-of-use" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

이 페이지의 콘텐츠는 선택하신 언어로 제공되지 않습니다. Elastic은 다양한 언어로 콘텐츠를 제공하기 위해 최선을 다하고 있습니다.조금만 더 기다려주세요!

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

내 표준 시간대로 웨비나 시작 시간 확인하기

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

참여가 어려우신가요? 등록하시면 녹화 자료를 보내드리겠습니다. 이메일로 관련 콘텐츠도 받아보실 수 있습니다.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

You'll also receive an email with related content

이메일을 통해 관련 내용을 보내드리겠습니다.

Thank you for registering. We will send you a confirmation email soon.

등록해 주셔서 감사합니다. 곧 확인 이메일을 보내드리겠습니다.

Author

Articles by Rok Orsic

Configuring a SAML realm for role-based access control in ECE

How to configure Elasticsearch SAML authentication with ADFS

Sign up for Elastic Cloud free trial