I am trying to configure OIDC integration with elasticsearch and kibana.
For development, I am using my own IdP based on KeyCloak. Everything works fine. Roles are read out of the JWT Token if I configure KeyCloak to add the roles information to the Identity Token (as described in https://search-guard.com/kibana-openid-keycloak/ )
In my production environment - using a corporate IdP based on Ping Identity - the IdP does not include the roles information to the identity token. I can access the user name based on the “sub” field in the token. But to access the roles information, it is necessary to query the OIDC userinfo endpoint.
Is there any way to configure SG to do so?
btw: the error message from the ElasticSearch log is:
Failed to get roles from JWT claims with roles_key ‘entitlement_group’
When I debug the JWT ID token, the roles key ‘entitlement_group’ indeed is not there since the IdP does not include it.
When I query the IdP userinfo endpoint manually, the entitlement_group key there with all roles.
- Debugging the JWT ID Token, the roles_key is there and authorization works.
- If I remove the roles_key mapping rule in Keycloak (so that the ID Token does NOT contain the roles_key), authorization also does not work.
So my conclusion is that SG does not use the userinfo endpoint from the OIDC Identity Provider.
ElasticSearch XPack supports the userinfo_endpoint - I wanted to go away from X-Pack, but this behaviour seems to block these plans.
Yes, right now SG doesn’t use the userinfo endpoint. I add this to the queue of the issues to resolve.
As a temporary workaround, maybe you can use scopes to specify what privileges are being requested for an access token. The scopes associated with the access token determine what resources will be available. In SearchGuard you have
searchguard.openid.scope to define scopes: Kibana OpenID | Security for Elasticsearch | Search Guard
Good to hear that you’re planning to include the usage of the userinfo endpoint.
Since the scopes are not customizable in the corporate environment, I’ll work with a different workaround:
- Using oidc for authentication
- Using ldap for autorization
Actually our AD based ldap has different identities than the directory used by OIDC, this seems to be only a dirty workaround to catch ~90% of the users.
The first test looks successfull as the backend roles are now gathered (I can see all my AD group memberships in Kibana).
I just want to chime in here as well. We have the exact same situation as described by @shakazulu. Our corporate IdP does not provide role information in the ID token. Our corporate setup requires us to use the userinfo endpoint to obtain the roles. Without this feature, we are currently not able to fully leverage the OIDC integration of Search Guard.
We will give a try to the workaround mentioned below (authorization via LDAP), but we would really appreciate, if we could switch to OIDC completely.
Yes, we are looking into it.