Allow SSO enforcement in group settings for GitLab.com
Description
We allow groups to enable SSO via SAML 2.0, but we don't enforce the use of this as an authentication scheme. As a result, users in these groups are still free to use their GitLab username/password to access these resources.
For security, we should allow a SSO-enabled group the option of enforcing authentication only through SSO. This would mean that any resources in the group (projects and sub-groups) would require using the configured identity provider - signing in with a GitLab username/password would be insufficient to access the relevant group.
Proposal
- After enabling SSO on a group, a group Owner should be able to enable an option on the group to enforce SSO.
- Without authenticating with the identity provider, a user should not be able to access the relevant group or any child resources in the web UI.
- Approach: for projects/subgroups, check for the user's last sign in with the configured SSO provider. If the last sign-in does not meet some threshold, then redirect the user to the SSO URL and do not present the requested resource.
- After the user signs in, they should be redirected back to their requested resource.
- Allow the group to define the authentication frequency, default 7 days.
- Approach: for projects/subgroups, check for the user's last sign in with the configured SSO provider. If the last sign-in does not meet some threshold, then redirect the user to the SSO URL and do not present the requested resource.
Edited by Jeremy Watson (ex-GitLab)