**What's the problem we're trying to solve?** -- Our [first iteration](https://gitlab.com/groups/gitlab-org/-/epics/40) of SAML for GitLab.com built the basic foundation for single sign-on. This iteration requires some manual work from group owners, and we should strive for an environment that doesn't require owners to provision/deprovision by hand. Without this epic: * Group owners will need to manually remove group members, even after they get removed from their connected identity provider. This is not convenient or secure. * Group owners need to manually set permissions for users who join the group. * Group owners don't have granular control over the users who are able to join the group. They're unable to restrict certain users from joining the group (even if they're recognized by the identity provider), and they're unable to set e-mail notifications from going to a user's personal e-mail address. **What's in this epic?** -- After this epic: * Creating, removing, and updating group members should require no manual effort. We plan on accomplishing this via SCIM. Where we go from here: * Allow Group-level SAML to limit access based on SAML assertions. Allow admins to only allow SSO access for certain user groups based on an attribute. * SAML permissions sync similar to LDAP Group sync to allow attributed to determine provisioning & permissions (Gold feature?) * Cross-link SAML instance-level credentials and group-level credentials * Allow filtering of the group list by members by SAML SSO status (linked or unlinked) **What does success look like?** -- We're able to win more GitLab.com Silver/Gold customers who value user management with SSO.