Open candlerb opened 2 years ago
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.
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 own sub value (for Google, it's a 21-digit number that they never see). Therefore I cannot pre-create the entity alias.
For this, instead of using sub
, use email
and add email scope to your policy via oidc_scopes="email"
. By doing this you can pre-create entities.
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! Any update on this feature? We suffer from a similar issue where we need to run terraform to onboard new users and if they've managed to auth to Vault and an entity/alias exists with the same username we hit collisions that require a manual TF import or manual entity deletion. Preventing the entities from being generated so we can run our onboarding process without conflict would be an immense help.
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