How to set up Okta SAML login for Kibana on Elastic Cloud

Identity Providers (IdPs) are responsible for providing users with web-based single sign-on (SSO) authentication and then sharing the user’s authorization criteria with designated service providers, like Elastic. Elasticsearch and Kibana support multiple SSO options. In this post, we’ll show how to secure an Elastic Cloud Kibana deployment with example IdP Okta via its Security Assertion Markup Language (SAML) 2.0 integration.

Once created, click the Copy endpoint button for Kibana and use it to fill out the KIBANA_URL placeholder of Elasticsearch’s SAML settings, which’ll go from

To

Kindly note the further placeholders above, which will be filled in as we progress with the Okta-side of our integration setup.

This will show a pop-in window labeled “Create a new app integration” form. Under “Sign-in method,” we’ll select SAML 2.0.

After clicking Next, we’ll be taken to Okta’s Create SAML Integration wizard. Under (1) General Settings, we’ll input an App name and App logo (optional).

After clicking Next, we’ll be taken to (2) Configure SAML. Under (A) SAML Settings, we’ll first cross-pollinate some of the earlier Elasticsearch SAML settings’ values. We’ll copy the value for “sp.acs” into Okta’s “Single sign-on URL” and the value for “sp.entity_id” into Okta’s “Audience URI (SP Entity ID)”. 

The next fields’ values depend on the Okta-side setup. For our demonstration, we’ll leave the default field states for Default RelayState, Application username, and Update application username on and update Name ID format to “EmailAddress.”

Scrolling down a bit, we’ll set Group Attribute Statements (Optional) to our target group “Everyone”.

Under (B) Preview the SAML assertion generated from the information above, we’ll then click Preview the SAML Assertion.

After clicking Next, we’ll be taken to a feedback form, and then we’ll finally have a created Okta application. Now let’s add this Okta application to an allotted Okta Group. For our demonstration, we’ll add it to the group “Everyone” by navigating Directory > Groups > Everyone > Assign applications and then enabling our application by clicking Assign.

We’ll finish by clicking Done, at which point the application will show under our Okta Group’s application list.

Now that we have a working Okta application, we can copy the Okta-generated values back into our Elasticsearch SAML settings. Our Okta application’s Metadata URL will replace our placeholder for “idp.metadata.path” and its “Issuer” (under More details) will replace our placeholder for “idp.entity_id”.

Based on our earlier Okta-side configuration, we’ll also be able to set “attributes.principal” to “nameid” and “attributes.groups” to “groups.”

Now that we have all Elasticsearch SAML setting values filled in, we’re ready to add the SAML settings to both the Elasticsearch and Kibana user settings within our Elastic Cloud Deployment. Under our Deployment, we’ll navigate to Edit to Customize our Deployment. For Elasticsearch, we’ll open Manage user settings and extensions > User Settings and paste-in our Elasticsearch SAML settings.

After clicking Back, we’ll scroll down to Kibana and open Edit user settings to paste in its SAML settings.

After clicking Back, we’ll scroll to the bottom and click Save and then Confirm.

This will induce an Elastic Cloud Deployment plan on our behalf and redirect us to the Deployment Activity page to monitor its progress.

Building off of our earlier example, let’s say we had created multiple Okta groups like “Admins”, “Support”, “Managers”, “Sales”, “Solution_Architects”, and “Engineers”. If only technical coworkers were supposed to access Kibana, we could have set Group Attribute Statements (Optional) to a comma-delimited list “Admins,Support,Solution_Architects,Engineers”. In this circumstance, it may make sense to have multiple levels of role mapping permissions.

In this situation, “Admins” would have built-in “superuser” role access in Kibana; “Engineers” would have write access via custom role “writers”; and remaining technical workers would have view-only access via built-in role “viewer.” Non-technical users would not have any access to the cluster.

This button will redirect us through an Okta authentication session and redirect back to Kibana.

Once logged in, we can navigate to our KIBANA_URL’s endpoint “/internal/security/me” to confirm Okta-shared metadata and resulting Elasticsearch Roles. For our “Everyone” and “Admins” examples above, this would map us to the “superuser” role.

The same test can be run from Dev Tools with Elasticsearch’s Authenticate API.

For our extended example, this would respectively show the “Engineers” as “writers” and “Support” or “Solution_Architects” as “viewer”. For non-technical coworkers who are not eligible for cluster access, they would instead receive a “You do not have permissions to access the requested page” error.

This confirms our Okta-to-Kibana SSO SAML integration has been successfully set up!

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.