Extend Role/Group Membership to support external members

[havetisyan]

Currently ZMS only allows existing service principals or groups to be a member of a role. This limits the use of the authorization server when there are use cases to support members that maybe not be referenced in the Athenz system.

For example, in a B2B use case, the system admin has configured access to a some UI using multiple identity providers - one for internal users and another one for external users (from security perspective we want to keep them completely separate). The internal identity provider is defined as the Principal Authority. We need a capability to reference the users from the external identity provider in our roles. Those users might not be authenticated as principals to manage resources but they need to be included in authorization policies.

The role members can currently be:

*
<domain>.*
<domain>.<service>
<domain>.<service-name-prefix>*
<domain>:group.<group-name>

So we need to a new member type where we can reference external members.

Requirements:

• Each domain can have a system attribute called externalMemberValidator which must point to a valid class responsible for member validation. ZMS will call this method to validate that the members (the <ext-member-name> part) is valid.
• We can have multiple domains with different validators with more flexibility and different validation rules.
• The members are always tied to a domain. If the domain is deleted all associated entries can be deleted at the same time.
• To provide full flexibility, the <ext-member-name> should be just a string and we should not impose any restrictions. The validator will be responsible for validating the member is valid.

Proposal 1:

Add a new type:

<domain>:ext.<ext-member-name>

For example:

email:ext.john.doe@athenz.io

The advantages of this new format:

• Consistency with the group member format. We're just adding ext as a new entity type in addition to group.
• No ambiguity when parsing the members. We know which ones are groups and which ones are members

The disadvantage of this new format:

• Seems like an extra component ext. included in the name. It's easier to follow members like email:joe@athenz.io and email:jane@athenz.io than email:ext.joe@athenz.io and email:ext.jane@athenz.io

Proposal 2:

Add a new type:

<domain>:<ext-member-name>

For example:

email:john.doe@athenz.io

The advantages of this new format:

• More natural format without extra components

The disadvantage of this new format:

• Ambiguity if the value specified is email:group.member-name. Is this referring to a group called member-name or it's an external member called group.member-name? The solution to this problem would be that if the domain is configured with an externalMemberValidator then it can't include services and groups and therefore group.member-name is referring to an external member.
• This could be a problem since in a lot of places we determine the type of the principal and we can't really do that easily unless we keep track of external domains somehow
• The solution can be handled correctly by athenz services, but other clients that are reading zms role members and making decision might get it wrong

[abvaidya]

I prefer option 1, to be consistent with existing member classification and if we need to extend membership to other types of principals in the future, it will be easier to do so.