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
OIDC Auth method: option to prevent dynamic entity creation, and for user to add entity alias #14989
Comments
any update on this? facing same issue |
same here, any updates? |
same here. Any updates? |
Does anyone have an update on this issue? It seems to be quite important. |
Hello! Thanks for opening this issue and providing the details. I will discuss with my team if this is something we want to support. We should have an update within the next few weeks. As soon as we do, I will update this thread. |
For this, instead of using I still like to prevent auto entities creation though. I also like to know how to have two role but letting only some users be able to authenticate with one of them, so the users who know the name of the non default role won't get access to vault with that role |
OpenID Connect strongly discourages use of email claim as an identifier: in fact it says it MUST NOT be used for this purpose. See OIDC core spec section 5.7 |
I understand, just wrote it as temporary solution for anyone who can use this, until a better solution arrives. And just a heads up, in Google, you can't change emails, so the worry mentioned in the OIDC spec doesn't really apply here. |
@fairclothjm Hello! Thanks! |
Hello, sorry for the late update. We do not have plans to implement this enhancement at this time. |
Is your feature request related to a problem? Please describe.
Scenario: you want to allow trusted partners to authenticate to Vault. One reason is so that you can grant access to applications which you host, and which authenticate against your Vault's OpenID Provider.
You don't want to manage the individual passwords for all these external users, so you connect Vault to one or more social auth providers using the JWT/OIDC Auth Method. For this discussion, let's say you choose Google.
There are two problems.
The smaller issue is that anyone with a GMail account can connect to your server and dynamically create an entity and entity alias. The 'default' policy allows various stateful actions such as creating child tokens and cubbyhole secrets, which makes it an easy target for denial of service (e.g. filling the database with garbage). This can be mitigated by setting
token_no_default_policy
, and explicitly granting thedefault
policy only to entities which have been added to a group. However, it would still be nice to avoid "drive-by" account creation, and the corresponding entity crud.Practically, I'd like to pre-create an entity for the user, and then connect their Google identity to it. But if I follow OpenID Connect best practice and use the
sub
claim as the user_claim, I won't know it in advance - indeed, most end users won't even know their ownsub
value (for Google, it's a 21-digit number that they never see). Therefore I cannot pre-create the entity alias.So at the moment the approach is:
Describe the solution you'd like
I'd like to see two things:
The mechanism I'm thinking of for (2) is as follows - assuming we've already created an entity for the new user.
https://vault.example.com/ui/add-alias?token=XXXXXXXX
Describe alternatives you've considered
Now that Vault has an "allow_all" assignment (#14119), it's possible to write a standalone registration server which performs almost the same. The user would connect to the web page, which would dynamically create an entity and entity alias. The registration server could then unwrap and validate the given token, and then perform an entity merge to combine the original entity with the one newly created.
This may be workable, but: (a) it relies on the "drive-by" dynamic entity creation, and (b) it relies on the registration server having its own token with sufficient super-user privileges to perform entity merging. If not done right, it may be subject to 'confused deputy' attacks which would allow one user to take over another user's account.
IMO, it would be much better if a user who has already authenticated as themselves, could be authorized to add a new entity alias to their own entity.
Explain any additional use-cases
With a little more work, this could also become a mechanism for user "self-care" to add their own OIDC entity aliases. e.g. if Vault has enabled auth methods Userpass, OIDC1 and OIDC2, then a user could login with Userpass or OIDC1, and then attach an entity alias for OIDC2.
Being able to remove aliases would be a corresponding feature. It should not leave the entity with zero aliases, of course.
Additional context
N/A
The text was updated successfully, but these errors were encountered: