OIDC with Elasticsearch

It seems every bit of documentation that I read has conflicting advice, and I'm stumped on this one. First of, I've never worked with OIDC or SAML before so this is my first exploration.

I'm trying to configure SSO so it will pull the "groups" from the user logged in, and map the correct role to the user.

This is the current elasticsearch config (although lots have been removed so you can see what I've done)

    xpack:
      security:
        authc:
          realms:
            oidc:
              oidc1:
                order: 2
                rp.client_id: "0000000000-0000-0000-0000-0000000000ETC"
                rp.response_type: "code"
                rp.requested_scopes: ["openid", "email"]
                rp.redirect_uri: "https://elasticsearch-cloud-instance/api/security/v1/oidc"
                op.issuer: "https://login.microsoftonline.com/tenant_id/v2.0"
                op.authorization_endpoint: "https://login.microsoftonline.com/tenant_id/oauth2/v2.0/authorize"
                op.token_endpoint: "https://login.microsoftonline.com/tenant_id/oauth2/v2.0/token"
                op.userinfo_endpoint: "https://graph.microsoft.com/oidc/userinfo"
                op.endsession_endpoint: "https://login.microsoftonline.com/tenant_id/oauth2/v2.0/logout"
                rp.post_logout_redirect_uri: "https://elasticsearch-cloud-instance/logged_out"
                op.jwkset_path: "https://login.microsoftonline.com/tenant_id/discovery/v2.0/keys"
                claims.principal: email
                claim_patterns.principal: "^([^@]+)@mydomain\\.com$"

I've also tried changing the claims.principal, removing claim_patterns to this after reading some mixed reports.. but no luck!

                claims.principal: sub
                claims.groups: ".*"

So I have the following role mapping created in Kibana:

PUT /_security/role_mapping/oidc-kibana
{
  "roles": [ "kibana_user" ],
  "enabled": true,
  "rules": {
    "field": { "realm.name": "oidc1" }
    "field": { "groups": "2192a737-0000-48c4-0000-d93baa330c48" }
  }
}

The above does not work, however when I take our "groups" in the role mapping then it does work successfully, so that tells me that the other bits I've configured correctly and it's just somehow not seeing the groups...

Using some other tools, I've managed to get the JWT and decode it, I can see that the "groups" attribute is actually being populated as shown however I have removed some bits after the groups..

    {
      "typ": "JWT",
      "alg": "RS256",
      "kid": "removed"
    }.{
      "aud": "removed",
      "iss": "https://login.microsoftonline.com/removed/v2.0",
      "iat": numbers,
      "nbf": numbers,
      "exp": numbers,
      "groups": [
        "2192a737-0000-48c4-0000-d93baa330c48",
        "8e4742de-0000-4248-0000-b1a13ab1d822"
      ],
    }.[Signature]

All of the documentation sends me round in circles to other documents, that are not consistent to the first or have different examples and don't quite explain it simply enough..

Does anyone have any clear examples on how I could get this working? I want to split say readers and admins out by their groupid's from our IdP.

Thanks for any help

O.

Hi Oliver. Thanks for your feedback. If you'd b so kind as to point out the documentation parts with conflicting advice, we'll do our best to make sure they are fixed so that they align and not create confusion.

Now to your question, have you read : Configure Elasticsearch for OpenID Connect authentication | Elasticsearch Guide [master] | Elastic ? It says :

claims.groups: "http://example.info/claims/groups" : Similarly, this instructs Elasticsearch to look for the claim with the name http://example.info/claims/groups (note that this is a URI - an identifier, treated as a string and not a URL pointing to a location that will be retrieved) either in the ID Token or in the UserInfo response, and map the value(s) of it to the user property groups in Elasticsearch. There is no standard claim in the specification that is used for expressing roles or group memberships of the authenticated user in the OP, so the name of the claim that should be mapped here, will vary greatly between providers. Consult your OP documentation for more details.

The name for the claim that your OP uses to express group membership is groups as seen in your

{
      "aud": "removed",
      "iss": "https://login.microsoftonline.com/removed/v2.0",
      "iat": numbers,
      "nbf": numbers,
      "exp": numbers,
      "groups": [
        "2192a737-0000-48c4-0000-d93baa330c48",
        "8e4742de-0000-4248-0000-b1a13ab1d822"
      ],
    }

so the correct configuration in elasticsearch should be

claims.groups: groups

Now you'll see that your role mapping

PUT /_security/role_mapping/oidc-kibana
{
  "roles": [ "kibana_user" ],
  "enabled": true,
  "rules": {
    "field": { "realm.name": "oidc1" }
    "field": { "groups": "2192a737-0000-48c4-0000-d93baa330c48" }
  }
}

will work. As in , it will assign the role kibana_user to any user logging in that has 2192a737-0000-48c4-0000-d93baa330c48 as one of the values in their groups claim in the ID Token.

Hope this helps

1 Like

Wow, I genuinely can't believe I missed this after getting all the other hard bits done. This threw me out for a good 4 hours, and I did read that page quite a few times but it was confusing me that the example wasn't referenced anywhere in the original "how to set it up" docs, and that the explanation for groups was very confusing, especially when you don't really know how it all hangs together.

I wonder if its possible to propose a change to the docs to avoid confusion, maybe something along the lines of..

claims.groups: "groups" - This is the name of the attribute passed within the token from your OP. The specific attribute can be obtained by <pointers> and identified when the token is decoded.

In terms of documentation, I was mainly reading https://www.elastic.co/blog/how-to-set-up-openid-connect-on-elastic-cloud-with-azure-google-okta which got me 99.9% of the way there..!

This link https://www.elastic.co/guide/en/elasticsearch/reference/master/oidc-guide-authentication.html, under claims.groups and claims.principal, it links to claims mapping, which kind of doesn't help, as that didn't really explain what I was after.

Everything you suggested worked perfectly, and I'm super gutted I didn't work that out.

Thanks so much for helping!

O.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.