OIDC - obtain roles using userinfo endpoint

Hello all!

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’

PingIdentity Test:

  • 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.

KeyCloak test:

  • 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: https://docs.search-guard.com/latest/kibana-authentication-openid#configuration

Thanks, Sergii.

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).

1 Like