I am enabling
oidc auth backend (using GSuite as my IDP).
I am also creating 5 oidc roles. (say
Is there a way to assign each corporate user to a role a priori, i.e. before the user logs in, so that when
firstname.lastname@example.org attempts to login via Google, he is assigned
role2 for example?
No, but I think you’re probably using roles incorrectly here.
These roles are essentially configuration profiles for the OIDC login method to handle unusual special cases only.
Almost everyone should just be defining one role only, and setting it as the default role, so their users don’t need to manually type a role name on the OIDC login page.
Thanks. So what is the way make a matching between GSuite users and policies? (if
oidc roles is not the way to go about it)
That is done via Vault’s Identity secrets engine.
You can define entities (users) and entity-aliases, which link a Vault entity (user) to the user’s name in the OIDC provider.
You can also define groups, and group-aliases to link to groups mentioned in the OIDC identity token.
Both entities and groups can have policies associated with them.
Yes I read that. The only issue that seemed odd to me is that for the OIDC in GSuite to be able to fetch the google groups membership you have to go through an elaborate process via GSuite Workspace, create a service account and so on. In any case I think I will go with entities and entity aliases naming each of my entity by its corresponding GSuite email.
What is more, I did not understand why the OAuth application (I assume within the project where GSuite resides) needs to be of external type so that
Projects configured with a user type of External are available to any user with a Google Account.
Isn’t that a security risk? What if I want to restrict users able to login only to the ones having
What are the roles trying to segment in the vault console? Here is an example of an SSH key signing role that we used with OIDC. It allows users to login only as their ID on a server where their Auth principle is provisioned.