ELK (Elastic) Stack Single Sign-On (SSO) with WSO2 Identity Server via OIDC

I’m mainly focusing on WSO2 Identity Server 6.0/5.11 and ELK version 8.X but I will mention the changes to support other combinations as well. To follow this guide, you need to have the following,

• Up and running Kibana 8.X (http://localhost:5601) and Elasticsearch 8.X (http://localhost:9200)
• WSO2 Identity Server (6.0 or 5.11)
• Basic knowledge on WSO2 Identity Server. It’s really easy to learn and get used to. It has guided tutorials with examples to learn it quickly. Give it a try if you haven’t already.
• Ubuntu 20.04 or other version
• ELK installed from “apt” in default locations (/usr/share/***)

I’m going to divide this tutorial into two parts as WSO2 Identity Server configuration and ELK configuration. Let’s start with the Identity Server configs.

WSO2 Identity Server SSO Configuration with OIDC

Following are the steps to cover,

• Create a service provider for ELK
• Enable the required claims
• Configure OIDC for SSO
• Edit openid scope to contain the groups array for role mapping (Only for WSO2 IS 6.0)
• Create a role for ELK and assign a user

Let’s move on to the steps now. First create a service provider from the carbon console. You can give it any name. Then go to “Claim Configuration” section inside the created service provider and expand it. Now, you need to add the following list of claims as “Requested claims” and username for the “Subject Claim URI”. If you have WSO2 IS 5.11 or below then use /claims/role instead of /claims/groups.

Configure claims in the created service provider

In the same service provider you created, expand the “Inbound Authentication Configuration” and click on “OAuth/OpenID Connect Configuration”. Now add a configuration and fill the settings as follows,

OIDC configurations

• Change the Allowed Grant Types to “Code” and deselect all others.
• Add this string as the Callback Url regexp=(http://localhost:5601/api/security/oidc/callback|http://localhost:5601/api/security/logout|http://localhost:5601/security/logged_out)

Keep everything else as default or change at your own discretion. Save changes and copy the Client Key and the Client Secret displayed as follows,

Client Key and Client Secret

avigate to “Manage -> OIDC Scopes -> List” and click on the “Add claims” button on the “Openid” row. Add the following claims and finish. (Skip this step if you’re on WSO2 IS 5.11 or less)

• email
• groups
• username

Edit the claims for openid scope

Create a user role such as “AnalyticsViewer” and then assign a newly created user for the role.

User Role Creation

Configuring ELK for OIDC SSO

Install ELK on your local machine or server. Preferred Ubuntu 20.04. Clone the following repository: https://github.com/Avarjana/identity-elk-integration-local. This repo containsself wrote scripts to make my life easier. Feel free to modify it and use. Send a PR if you have any improvements to be made.

Please note that the SAML SSO configuration is not working and I’m looking into a fix. Do not change anything related to the SAML config.

Elasticsearch configs

Open “elasticsearch/elasticsearch.sh” file and replace the code in line 18 with your client secret.

Client Secret

Open “elasticsearch/elastic.yml” file and replace the “rp.client_id” (line 28) with your client key. Save and start elasticsearch by executing “sudo sh elasticsearch.sh”

Kibana configs

Open “kibana/kibana.yml” and check if following configuration is in place. You can change or add icons to this configuration if you want.

Kibana OIDC config

Start kibana by executing “sudo sh kibana.sh”. Login to your admin account in kibana via “Log in with Elasticsearch” option as usual.Go to “Stack Management -> Security -> Role Mappings”

Role mapping section

Create a role mapping as follows and save it.

• Mapping Name : Dashboard Viewer
• Enable Mapping : True
• Roles : viewer, monitoring_user

Add mapping rule as follows,

• User field : groups
• Type : Text
• Value : AnalyticsViewer

Role Mapping

Open an incognito window and login with WSO2 to Kibana and use the credentials of the user we created earlier. If everything goes according to the plan, the user must have the privilages of “viewer, monitoring_user”.

Let me know if you faced any difficulties in the process :)

🥰🤘🏽 WSO2 Identity Server → Deliver Seamless Login Experiences🤘🏽🥰