Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A use case has come up in discussion with groups from SKA (highlighted by the Canadian 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.

...

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.

...