### What's the problem we're solving? Supporting centralized identity management is must-have configuration for enterprises. It provides security (employees should only have access to what they need, when they need it) and convenience (administrative manual effort is reduced, access is managed centrally and automatically). By managing employee records in one place, a company is able to update authentication and authorization everywhere and manage at scale. Our plan is to achieve two key capabilities, respectively: 1. Allow groups to [enforce single sign-on](https://gitlab.com/groups/gitlab-org/-/epics/94). User should be required to authenticate through a connected identity provider, and not able to access a group's resources with only instance (GitLab.com) credentials alone. (goal: 11.8) * Iterate by allowing a group to [enforce dedicated user credentials for group access](https://gitlab.com/groups/gitlab-org/-/epics/709). Isolate personal projects from work and force notifications to go to the employee's email address on the identity provider. (goal: 11.9) 2. [Manage group membership through SCIM](https://gitlab.com/groups/gitlab-org/-/epics/95). Prioritize removing users from the group on being removed from a supported identity provider (e.g. Azure AD). (goal: 11.9) ### Solution From [this presentation](https://docs.google.com/presentation/d/1xLakH3K62ZbMoEGvcoVSbN5FS1iVi8ZpQdcO5CuDwrU/edit#slide=id.g3ff367abb9_0_5):  We're prioritizing security over convenience as we iterate on our first iteration of [Group SSO](https://docs.gitlab.com/ee/user/group/saml_sso/). In this epic, we'll give enterprises a way to configure a group to securely manage employees and maintain clear separation of concerns between a personal account and a dedicated user account for their enterprise activity. ##### Goal for 11.8: SSO enforcement In 11.8 (mid-February 2019), the goal is to achieve **basic SSO enforcement** for SAML SSO enabled groups. This would require that users authenticate with the configured SSO provider for a group before being able to interact with projects or subgroups underneath that protected namespace. See the following activity diagram for an example of a user attempting to access the project overview page in a namespace that's enforcing SSO:  Notes: * The above is relevant for the UI, but we plan on performing the same session check on [SSH/API activity](https://gitlab.com/gitlab-org/gitlab-ee/issues/9152). * A user must have a pre-existing user account. A new user flow for registering a new user is [planned for 11.9](https://gitlab.com/gitlab-org/gitlab-ee/issues/5292). ##### Goal for 11.9: SSO enforcement with dedicated user credentials In 11.9 (mid-March 2019), we'd like to build on SSO enforcement by enabling dedicated user credentials for SSO-enabled groups. This provides an extra layer of security by requiring a dedicated account for interacting with a group and preventing a user from changing their email away from the address associated with their corporate identity. See the following activity diagram for an example of a user attempting to access the project overview page in a namespace that's enforcing SSO with dedicated credentials:  Notes: * Of note is the added group attribute that defines a list of specific `User.id`s that may SSO directly into the group. If an authenticated user is not found, they must register a new account with their email address from the SAML response, where the newly registered `User.id` is added to the group as an accepted dedicated user. We'll also introduce a new user flow, if the authenticated user does not have pre-existing user credentials on the instance. After registration, we'll create a session and redirect the user back to the requested resource.  Finally, we'll begin SCIM 2.0 support beginning with removing users from a group through a SCIM API endpoint: 1. [Remove an existing user](https://gitlab.com/gitlab-org/gitlab-ee/issues/5014). Remove the user from the group's membership and from recognized dedicated user credentials (if being used by the group). If the user is re-added to the identity provider, they'll be treated as a brand new user. ##### Goal for 11.10: Support for user provisioning with SCIM We'll also introduce several endpoints that enable member provisioning/deprovisioning for the group. In order of priority: 1. [Create a new user](https://gitlab.com/gitlab-org/gitlab-ee/issues/9201). An SSO configured group should be able to provision a new user from the identity provider. 1. [Update an existing user](https://gitlab.com/gitlab-org/gitlab-ee/issues/9154). If information changes on the identity provider for an existing user, attributes in GitLab should update appropriately (e.g. email). We'll also add [polish](https://gitlab.com/groups/gitlab-org/-/epics/97) to the user experience and make configuration easier.