Using groups from oidc in claim_mappings and as template variables inside policies.

[boniek83]

I don't want to synchronize users and their groups from my oidc provider (gitlab where my code resides) to openbao. I want openbao to use what's already there.
I would love it if something like this was possible (it doesn't have to be exactly like this, I've chosen this so it somehow fits in current model):

kubectl exec -it openbao-0 -- bao write auth/oidc/role/gitlab-users
allowed_redirect_uris="https://openbao.local/ui/vault/auth/oidc/oidc/callback"
role_type="oidc"
user_claim="sub"
ttl="1h"
oidc_scopes="openid email"
verbose_oidc_logging="true"
groups_claim="groups"
token_policies="basic"
claim_mappings="groups=groups" <--- currently impossible, this only maps simple strings, doesn't understand arrays

basic.hcl:

Read/write access only within your OIDC group(s)

path "secret/data/{{something.that.resolves.groups.to.its.elements.and.creates.as.many.path.entries.as.there.are.groups}}/" {
capabilities = ["create", "update", "read", "list", "delete"]
}
path "secret/metadata/{{something.that.resolves.groups.to.its.elements.and.creates.as.many.path.entries.as.there.are.groups}}/" {
capabilities = ["read", "list", "delete"]
}

Of course:
{{something.that.resolves.groups.to.its.elements.and.creates.as.many.path.entries.as.there.are.groups}}
this doesn't have to look like this, it could be (and probably should be) like iterating over array in go template.

In short I would love it if I could externalize group definition and maintenance to a system that already does this and is highly relevant to what I'm trying to achieve - my code repository. If someone has access to a code repository it means it should have access to secrets pertaining to it. I already have gitlab and people that manage it. Openbao should be able to just use it as it is.
Thoughts?

[DrDaveD]

@cipherboy is this related to #493?

[cipherboy]

Yes, I think so.

I think this could be done separately, but part of the problem is the policy would only work for one auth method/role/groups-list, as we don't have any ability to support optional components.

Edit: misread the original description. There's no easy way to support creating multiple entities out of a template sadly; this is a shortcoming of the custom templating language coupled with its interaction with HCL files. (What you parse must first be valid HCL, even without templating applied to it, which is rather problematic.)

I don't think it is really possible, short of using CEL for policies, which is discussed in #514 and #1212. JWT here is a relevant-source of auth information, but CEL in JWT doesn't actually solve the problem.

So I've currently proposed https://gist.github.com/cipherboy/65eef303127f7ee259498e45a2077ba1 to unify CEL semantics which also starts proposing CEL for policies and how that'd work.