You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
@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.
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?
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
The text was updated successfully, but these errors were encountered: