OIDC Auth method: option to prevent dynamic entity creation, and for user to add entity alias

[candlerb]

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.

1. 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 the default 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.

2. 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.

So at the moment the approach is:

• Wait for the user to make a "drive-by" authentication, which creates an entity and entity alias
• Scan through all unknown entities and identify the newly-created entity somehow - e.g. from one of the other claims on the entity alias.
• Configure this entity with necessary authorizations - or merge it into a pre-existing entity for this user.

Describe the solution you'd like I'd like to see two things:

1. A way to disable, at the level of an individual auth method, the dynamic creation of entities and entity aliases. If a user authenticates with an entity alias which doesn't exist, then the login is simply rejected with "user not known".
2. A way for a user to authenticate themselves as an existing entity, and add a new entity alias from another auth method.

The mechanism I'm thinking of for (2) is as follows - assuming we've already created an entity for the new user.

1. Create a wrapped token which authenticates as this entity.
2. Get the wrapped token to the end user somehow, e.g. by sending it in an E-mail to an E-mail address we already know they have. This can be in the form of a link, e.g. https://vault.example.com/ui/add-alias?token=XXXXXXXX
3. The user clicks on the link. It does the following steps:
   • Authenticates the user using OIDC (as part of hitting the web page)
   • Unwraps the token and uses that to authenticate as the selected entity
   • Creates an entity alias from the OIDC identity to the selected entity

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

[rpuserh]

any update on this? facing same issue

[nia-potato]

same here, any updates?

[fortis-lt]

same here. Any updates?

[abexamir]

Does anyone have an update on this issue? It seems to be quite important.

[fairclothjm]

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.

[tavrez]

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

[candlerb]

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

[tavrez]

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.

[dhelms-bw]

@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!

[fairclothjm]

Hello, sorry for the late update. We do not have plans to implement this enhancement at this time.