...

A use case has come up in discussion with groups from SKA (highlighted by the Canadian SRC SKA Regional Centre via CADC), augmenting the guidance around authorisation. Specifically, the "standard model" of "user joining group" is not sufficient, we also need groups to be able to join groups and to have multiple parents. The use case arose specifically in supporting the Rubin Observatory

This document covers only authorisation. Authentication to resources would have happened prior to the authorisation check.

Details

In the following, the term "team" is used as a synonym for "group" with the following additional property: the team can be a subgroup of multiple groups.

In the example below, a User joins a Team.  The team as as a whole joins one or more groups and gets authorisation through the group. Users may join or leave the team independently of which groups the team is part of.

Image AddedWhenever authorisation is required, the User gets authorisation from all the groups that the team is a member of.

Example

1. Users A, B and C join team T.
   1. At this point, users A, B, C have authorisation <NAMESPACE>:group:T (in the sense of G002)
2. Team T joins groups X, Y
   1. At this point, users A, B, C have authorisation <NAMESPACE>:group:T  and <NAMESPACE>:group:X:T and <NAMESPACE>:group:Y:T
3. User C leaves T
   1. At this point, users A, B have authorisation <NAMESPACE>:group:T and <NAMESPACE>:group:X:T and <NAMESPACE>:group:Y:T
   2. At this point, user C has authorisation <NAMESPACE>:group:X  or <NAMESPACE>:group:Y  only if they have it by independent means (not through T)
4. T leaves Y and joins W
   1. At this point, users A, B have authorisation <NAMESPACE>:group:X:T and <NAMESPACE>:group:W:T in addition to <NAMESPACE>:group:T 
5. User D joins T
   1. At this point, users A, B, D have authorisation as in point 4

Implementation Considerations

Attribute authorities

This use case should not require changes to the expression of group membership.

However, implementations of attribute authorities providing group attributes should implement a type of group which can request membership of, and be a member of, multiple groups, similar to a person. These groups (called "teams" in the above description) MAY be implemented differently from other groups.

Implementers SHOULD consider a role of "team leader" who not only manages members of the team but also the team's membership of groups. Potentially these could be two separate roles.

The group leader SHOULD be able to review membership of the team at all times (see security considerations). The group leader SHOULD be notified when team membership changes.

Resource Admin/Implementation

Resources MAY grant access to team T independently of their membership of parent groups.

Security Considerations

1. The highest risk associated with this proposal is that authorisation is inadvertently granted to someone who shouldn't have it, or is not removed from someone who have had it or is no longer authorised, due to the extra management layer. In this respect, the Team works like a subgroup with a separate manager from the parent group, except that the manager is not initially a member of the parent group and the group leader has no control over the subgroup: In the example above, suppose user A is team leader for team T, and user E is group leader for group X. Either A requests that T join X or E joins T into X. Membership of T is wholly managed by A and is not under any control of E; E can only add or remove T as a unit.

The risk is that unless E can review the membership of T at the time of T joining X, a user in T is granted access to resources authorised through membership of X.  Additionally, membership of T will change from time to time outside of E's control.

2. Another risk is that B (say) is a member of team T which in turn is a member of groups W, X, Y. At this point, B has rights associated with memberships of all these groups. If the system allows B to retain all of these at the same time (as opposed to selecting which ones they need as with VOMS), B will have very powerful credentials.