Prevent projects from being shared outside a GMA group
When enforcing SSO and group-managed accounts, the desired experience is to require SSO for access to any projects and subgroups within a top-level group.
However, it's currently possible to share a project within a group enforcing SSO with a group outside of the top-level group's namespace - or by adding members outside the group directly to a project. While this has to be initiated by the group's Owner, this edge case has the potential to effectively subvert SSO enforcement.
- When SSO enforcement is enabled for a group, present an error if:
- A user attempts to share a project in the group outside the top-level group.
- A user attempts to add members to the project who are not members of the group enforcing GMA.
- This should apply to projects in the GMA group, as well as projects forked from those projects.
- Sharing projects with subgroups within the top level group should be possible.
"GMA" here refers to Group Managed Accounts.
Availability & Testing
What risks does this change pose to our availability?
- Any existing access of groups outside the top level GMA group shared with a project in a GMA group gets revoked. (Would this be intentional/expected behaviour?)
- For forked projects, any existing access of groups outside the top level GMA group shared with the forked project in a GMA group gets revoked.
- The restriction is applied to SSO enabled groups that do not have GMA enabled.
- Share with group lock functionality breaks and allows sharing with groups with the same top-level group.
What additional test coverage or changes to tests will be needed?
Tests and at unit and feature level should provide enough coverage. New End-to-end tests should not be required however, we should run the
package-and-qa job before merging to ensure current tests are fine.