Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Token Metadata in templating engine #311

Open
UXabre opened this issue Apr 29, 2024 · 2 comments
Open

Support Token Metadata in templating engine #311

UXabre opened this issue Apr 29, 2024 · 2 comments

Comments

@UXabre
Copy link

UXabre commented Apr 29, 2024

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
Copy link
Contributor

@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
Copy link
Author

UXabre commented Apr 29, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants