Add functionality to check against a list of claims

[mjrlee]

If a list of claims is provided, unmarshal it and then search within that for the bound claim.

The intention is to allow me to pass a claim like:
vault_role: ["admin", "superadmin"]

This will allow me to log in as either admin or superadmin as I choose.

Useful for testing roles that other users have, or to allow people who sit across two teams to perform functions in both without adding additional roles.

[chrissphinx]

@MartinLeedotOrg have you confirmed this is working? I tried to build vault from source with this patch applied, but I am still unable to authenticate despite being in the GitLab group I am checking for.

I tried both:

  "bound_claims": {
    "groups": "group1"
  }

and:

  "bound_claims": {
    "groups": [ "group1" ]
  }

without any success. 😞

[mjrlee]

Did the first case work before the patch?

I haven't tested this with Gitlab's groups - only with Okta and passing arbitrary claims.

Are you requesting the groups scope from Gitlab?

[kalafut]

@MartinLeedotOrg Thanks! The JSON parsing is all handled upstream so I've adjusted that bit and added a couple more tests. I just tested this against Gitlab groups and it now appears to work OK.

@chrissphinx Maybe give this update a try?

[chrissphinx]

@kalafut no, unfortunately still not working for me. Perhaps I have built the binary wrong, I suppose we will wait for this to come through on official release to test out then.

[kalafut]

@chrissphinx Can you post your gitlab role config here (w/o sensitive data)?

[chrissphinx]

Sure it's:

{
  "user_claim": "sub",
  "policies": "employee",
  "bound_claims": {
    "groups": "group1"
  },
  "allowed_redirect_uris": [ "https://<vault_url>/ui/vault/auth/oidc/oidc/callback" ]
}

I have also tried it like:

{
  "user_claim": "sub",
  "policies": "employee",
  "bound_claims": {
    "groups": [ "group1" ]
  },
  "allowed_redirect_uris": [ "https://<vault_url>/ui/vault/auth/oidc/oidc/callback" ]
}

There wouldn't be any weird reason I couldn't just drop the newly built-from-source vault binary into my server, right? I don't have to destroy and remake the OIDC auth method from scratch?

[kalafut]

@chrissphinx The plugin hasn't been updated in the Vault repo yet which is why you're not seeing the change. To test it out now you'd need to build the plugin binary and register it with Vault. We'll merge the plugin into the main binary when we approach the next release.

No, you should not have to remake the OIDC auth method you've set up. You can always choose to mount another one at separate path if you want to run tests first, however.

[chrissphinx]

@kalafut yeah so what I did was clone down the main vault repo and then remove the vault-plugin-auth-jwt folder and clone down this repo in it's place. Then I built the binary. Maybe that process will not work?

Looking forward to the next release then, thanks for all the hard work! 👍

[kalafut]

@chrissphinx That process would work if you're not using Go modules, so it depends. If Go modules are used, then then vendor folder is ignored and the Go module cache is used. To do the same hack but for Go modules you could modify go.mod to point to a specific commit for jwt repo (since it hasn't been tagged yet. details: https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies). Then go build will fetch that version.