discuss: change policy to support unique entity id's only

[desimone]

Is your feature request related to a problem? Please describe.

Pomerium currently supports writing declarative authorization policy using allowed_users,allowed_groups, and AllowedDomains.

OIDC has very few "standardized" claims.

Some providers return all the data pomerium would want as part of the returned ID TOKEN however, that's the exception to the rule. For identity providers that do not provide fields like email, and group details, the authenticate service makes follow API calls to the identity provider to fully 'hydrate" pomerium user session.

Unfortunately, currently this means allowed_users or allowed_groups means different things to pomerium's policy depending on what identity provider you are using.

For groups, this means:

• Google uses email address ([email protected]) which is unique, but not immutable
• Okta uses group UUID because no other field is unique or immutable
• OneLogin uses group UUID because no other field is unique or immutable
• Azure uses group UUID because no other field is unique or immutable

For users:

• All the providers with the exception of azure reliably return email as part of either the initial id_token, or as part of the follow up rest call the the UserInfo.

This has caused confusion and possibly unintended security issues in the past when identity providers like GitLab used name to map group entities to policy.

This is complicated even further when some providers like Azure AD are not guaranteed to return a user's email at all. #520

Describe the solution you'd like

Policies should be written using entities unique id only (typically sub for user, and id for groups as part of the follow up group api call).

PRO

• This would ensure that policy remain explicit and immutable.
• Identity provider implementations would be standardized which would improve multi-IdP support amongst other things

CON

• Breaking changes. We'd be asking user's to rewrite their policies using user id and group id not user email and group name (in the case of gsuite).
• Worse user experience (most operators know the group names they are working with, but seldom know the group ids).

Describe alternatives you've considered

Keep things as is they are.

Explain any additional use-cases

Additional context

• The planned GUI for policy management could be used to offset the UX issues of using ID to write policy (we could do a rest call in the background to lookup an entity's ID, while still letting the operator use the human friendly entity name / email).

[desimone]

I think a reasonable solution is to add both Group ID and a user-friendly name to the group membership mapping. Though there would be a bit more data duplication, and it puts the onus of using an appropriate identifier on the operator, I think this is probably the best of both worlds.

[laszlocph]

Right now with Github, none of allowed_users, allowed_groups, and AllowedDomains give the right options for me as an operator. I want to grant access to everyone who is part of a Github org.

• allowed_users does not scale

• As an org matures, first I need to grant access to everyone who is part of the Github organization.
  Today this is not possible.
  AllowedDomains might achieve something similar, but an email domain != org membreship. Like with projects with many collaborators from many organizations..

• allowed_groups means a Github team. Which only make sense in unison with a Github org. I read the discussion about unique team IDs, but that just doesn't make it easy to operate Pomerium. Github org filter is much needed imo, and a team sub selector.

I understand that allowed_users, allowed_groups, and AllowedDomains mean different things for providers, and the desire to make it uniform across providers. But this is more of the desire of the maintainer, and not the operator. Me as an operator I look up the provider I prefer, and copy the config. I don't value the uniformity. Most importantly, today I can't limit access to org membership on Github. This is a problem.

[adinhodovic]

Hmm, if my Google groups are postfixed with the domain why can't Pomerium do the same for Github? Also the id seems to be shifted from a unique var to a fixed name for Github, also tried authenticating through the team id.

Current google implementation example:

23040124012 | [email protected]

Current Github implementation example:

admin(!!not even an unique id) | admin

The samples above are taken from the /.pomerium endpoint.

Expected Github example:

<github unique team id> | admin/<org> or admin@<org>