OKTA OIDC login - not getting the claims I need/want

Vault
1

I’ve set up a okta OIDC app and configured vault according to https://github.com/ncabatoff/vault-1.1-webinar/blob/master/README-oidc.md. Login works if the user_claim is sub.

I try to set it to “preferred_username” which I’ve used with other OIDC applications and okta. With vault I only get this:

Error
claim “preferred_username” not found in token

I’ve also set up okta to pass a groups claim which is also not passed. I can see that the groups claim should be passed in the token previewer in okta…

Enabeling verbose_oidc_logging I see this in the log:

OIDC provider response: claims={“amr”:[“swk”,“pwd”,“mfa”],“at_hash”:“”, “aud”:“”,“auth_time”:1591272834,“exp”:1591277580,“iat”:1591273980, “idp”:“”, “iss”:“https://schibsted.okta.com”, “jti”:“”, “sub”:“00u1ctd6mp51PYINY0h8”, “ver”:1}

So clearly no preferred_username or groups claim. If I change the user_claim to sub and remove the groups claim requirement it all works. BUT I need to give different groups of people access to different KV stores so that won’t do.

Has anyone used Vault with OKTA OIDC and gotten groups to work?

2

In Okta w/ OIDC I had a note that the only way to have the groups returned is to set Include in token type to ID (not Access)…
That was in Okta’s UI in Scopes >> Add groups scope >> Claims >> Add Claim

I had used this as a starting point: https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/overview/

3

I had fooled with the token configuration in okta with no real win.

After reading various docs refering to “fat tokens” and the scopes I realized that in some other setup I had set the oidc scope to “openid profile” and also “groups”. When I did that I got not only the preferred_username but also the groups claim.

4

More concretely, the oidc default role/role that is used for vault login needs something like this:

$ vault read auth/oidc/role/policy_by_group
Key                        Value
---                        -----
allowed_redirect_uris      [http://<internal server>:8200/ui/vault/auth/oidc/oidc/callback http://<internal server>:8250/oidc/callback http://localhost:8250/oidc/callback]
bound_audiences            [<openid client id>]
bound_claims               <nil>
bound_claims_type          string
bound_subject              n/a
claim_mappings             <nil>
clock_skew_leeway          0
expiration_leeway          0
groups_claim               groups
not_before_leeway          0
oidc_scopes                [openid profile groups]
role_type                  oidc
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              0s
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             []
token_ttl                  0s
token_type                 default
user_claim                 preferred_username
verbose_oidc_logging       true

The key being the oidc_scopes setting including “profile” to get the preferred_username and some other claims and “groups” to get the groups claim.

The verebose_oidc_logging true was most enlightening. On centos/rh the log can be followed by “journalctl -u vault -f”

5

Hi,
Can you share your vault write command to get the above configuration written to vault?

Thanks.

6

vault write auth/oidc/role/admin bound_audiences=“xxxxxxxx” allowed_redirect_uris=“http://xxxx:8200/ui/vault/auth/oidc/oidc/callback” allowed_redirect_uris=“http://xxxx:8250/oidc/callback” user_claim=“sub” policies=“secret_ro” oidc_scopes=“openid profile groups” groups_claim=“groups” verbose_oidc_logging=“false” token_policies=“admin” bound_groups=“HashiCorpVault_Admin”

7

I was on vacation. It looks like you found the right write command? Is it working now?

8

Hi, Thanks for the response. Yes. It is working now.

But, i still have not figure out how to read the oidc debug log effectively. I got a lot of logs. but, cannot tell if the token return is missing any claim.

mind to show some example of your log?

Thanks.

9

Hi,

I’ve disabled debugging by now and the logs have expired. It was pretty plain that the group claim was included in the JSON in the log. It was like the snippet I posted originally just with a lot more content (since this was the minimal claim I originally got):

10

Thanks for sharing. Search through my audit log, cant see anything similar

What I have is something like this:

  • “request”:{
    • “id”:“7e8b6849-452f-a07a-0dc7-15a06f858213”,
    • “operation”:“read”,
    • “mount_type”:“oidc”,
    • “namespace”:{
      • “id”:“root”},
    • “path”:“auth/oidc/oidc/callback”,
    • “data”:{
      • “code”:“hmac-sha256:de6889fc4a36d6e7ae36daf1f7c2883542a450cda0de9fa06cb78a4c563347da”,
      • “state”:“hmac-sha256:0bee12f92f5e0cef0d5cdfc7a47e4275bbc10272583825ce2173f5c0673a72c6”},
    • “remote_address”:“10.6.1.22”},
  • “response”:{
    • “auth”:{
      • “client_token”:“hmac-sha256:ac57616b07697cb1b25df9c4e6f8a8cb7af673aa54435b3e3ba4031c5914b974”,
      • “accessor”:“hmac-sha256:4ff283d489920baea66f0787f0b0942442b528def6e1d950fead5ef6350a93c4”,
      • “display_name”:“oidc-00udhbc2c6K8oHFEu4x6”,
      • “policies”:[
        1. “admin”,
        2. “default”],
      • “token_policies”:[
        1. “admin”,
        2. “default”],
      • “metadata”:{
        • “role”:“admin”},
      • “entity_id”:“ca8d92fd-2849-eb2e-2bbd-23ae69be315e”,
      • “token_type”:“service”,
      • “token_ttl”:2764800},
    • “mount_type”:“oidc”}

}

11

There should be a “claim=” somewhere in the responses if your configuration works at all. Does it work at all - without profile and groups claims?

I’m fiddeling with a different part of our ldap divestment right now but I’ll see what I can get logged and post here within some days.

12

Ah, I found it.
Its in the serverlog. not in the audit log.

Thanks.