Support Token Metadata in templating engine

[UXabre]

Original: hashicorp/vault#9763
Extra ref: hashicorp/vault#10460
PR with possible fix: hashicorp/vault#10682

My Goal
I’m currently trying to work through a use-case in which I’m using Keycloak (and thus JWTs) to authenticate against different realms (multi-tenant). I configured my jwt backend to copy some claims to the metadata section, as I’d like to simply write a single policy which applies to all customers by using template variables which substitute a part of the resource path with metadata claim.

The Problem
However, I noticed I can only do this if I know the backend-id (since jwt metadata isn’t available in the identity metadata); however, since this is multi-tenant, and I’d like to prevent my provisioner to be able to create a policy for each tenant (as this could lead to my provisioner writing a policy which allows admin rights!

The solution?
But I also saw that , using /auth/token/lookup-self we see the metadata for my jwt, which looks as if there’s a way that I should be able to do this in my template as a substitution variable, without me actually having to know the auth backend. Not sure if anything like {{token.meta.claim}} exists or if anybody knows a workaround for this?

Extra considerations (so many years later)
Apparently adding metadata can be added at various points, and is not per se validated. Perhaps an added step would be that we can flag or tag metadata injected by the auth engine as being authorized or something

[cipherboy]

@UXabre I think Nick had mentioned on the extra ref that you could tie this to an entity and add entity metadata that supports templating, today, iirc. With Vault this is an issue for two reasons (entity creation needs to be managed somewhere, and then entities are used for billing which drives up cost). But since you're already explicitly provisioning the metadata anyways into the token it seems like creating entities wouldn't be that much harder. And there's no entity billing concern here. :-) but, this would let you change auth methods in the future and not have to migrate all your metadata.

Thoughts? Let me know if you want a more concrete example.

[UXabre]

Thanks for your reply! However, I'm not sure I understand correctly? Does this mean I need to create an entity for each user in my identity provider? Because these are managed by different people and can be added/removed quite dynamically and keeping Vault/OpenBao's entities in sync seems error prone? (but like I said, I'm probably misunderstanding) or are entities auto-provisioned the first time one logs in (sorry for the stupid questions)?

This is a long standing "issue" btw and much of it's lore is losts to the sands of time for me :p I noticed that every blue moon somebody created a similar PR or a similar issue and since this problem is still alive and kicking for us, I thought giving it a fresh start on this fork :-) (and a fresh start in this community)

I'm probably the most confused what the exact use-case was/is for syncing jwt data into metadata if I cannot access it anywhere? Or is this synced with these entities?

[cipherboy]

@UXabre Apologies for the delay in getting back to you. I'd be curious to see the patch you have in mind.

But I will note that we don't have a paid model; a lot of objection of upstream customers to using entities comes from the client count billing model. So creating a separate entity for different, well, entities (ha) or users, especially if they should have different permissions, makes a fair bit of sense here. My 2c.

I think entities would be manually synced, though I've not looked into this for a bit.

[jmls]

TL/DR;

1. Is there a way of passing arbitrary metadata to the jwt creation
2. Has someone figured out a different way
3. does this ticket cover my needs ? :)

this ticket may address an issue I am currently facing. We use vault to generate a jwt which is then passed into spring security and then converted into an internal security object (an openedge client principal if you're mad enough to want to know .. )

This CP needs some data in the jwt that is supplied by our app - and the only way we have found to be able to add "extra" data to the jwt was to customise the identity_store_oidc.go program to accept an extra "metadata" parameter , which then updates the entity metadata which can then be used in the template.

It's an ugly, ugly hack - and something I'm not proud of, but being a non-go programmer was the best (at the time) I could come up with

[cipherboy]

Hey @jmls -- to clarify, this has to do with the use of metadata from the OpenBao token in the ACL (or PKI) templating. There, you have to know exactly what the mount's accessor is, to be able to write the PKI role or ACL policy to be able to use the metadata attached to the token. Any such role or policy isn't directly usable by another auth mount because it has different accessor values and will thus evaluation even if it has the same metadata. It looks like the identity token system can use the same logic to template custom claims onto the final JWT based on my read of https://openbao.org/docs/secrets/identity/tokens/

If you're using another auth method and trying to get JWTs out, yes, this would be a useful enhancement for you.

If on the other hand, you just want static values, template takes an arbitrary JSON object to copy; there's no requirement that it's fields be metadata template values. See https://openbao.org/api-docs/secret/identity/tokens/#create-or-update-a-role.

HTH!