GitLab Next

Problem to solve

While we're enforcing SSO, we should similarly enforce SSO outside of the GitLab UI. For the purposes of security, this gives enterprises a greater degree of control over protected resources. This is especially important for GitLab.com customers given multitenancy.

Proposal

We should perform the same check on Git activity that we do in the UI:

• When a user attempts a clone, push or pull with for a project in a group that's enforcing SSO:
  • If the represented user does not meet the SSO login threshold, present them with an error. "Cannot find valid SSO session. Please login via your group's SSO at https://gitlab.com/users/sign_in?"
• Users will need to log in via the UI and then attempt the Git operation again.
• Enabling Git SSO check should be a configuration option at the group level.
• Credentials that are not tied to human users should not have an SSO check enforced (Project Access token, deploy keys, etc).
• SSH and HTTPS Git activity should both be checked.

Note from @jamedjo: "Add check to UserAccess and user_access_denied_reason.rb to be displayed from GitAccess#check_active_user!. UserAccess changes can either be in the policy (:push_code and :read_project) or could be in UserAccess directly."

Issue readiness

• Product: issue description is accurate with an acceptable proposal for an MVC
• Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated