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.
Ensure SSO enforcement covers all access to resources and prevents access
Ensure that controllers that don't user find_routable! or authenticate_user! still check SSO enforcement, but also check they still work rather than always blocking access
Access checks when looking up multiple groups/projects at once such as from the projects dashboard
How will this interact with areas that only use token authentication such as RSS feeds?
Some kind of review for missed areas
Remove feature flag for SSO enforcement
SSO enforcement redirects to SSO page when access prevented
@jeremy The description mentions a 7 day timeout, but I remember some customers also wanting to ensure that the current session had used SSO rather than having logged in with a password.
In the prototype I'm requiring the current session to have used the group's SAML to sign in. Does that sound sensible? For SSH/API access we'd still use the 7 day timeout alone
Given we have now moved the access checks in to a new Issue, it seems reasonable that this Issue should cover adding the setting and the UI flow to enable it?
In regards to point 6, it seems this is a mix of a review and a test plan. I have added a couple of your comments to the scope of https://gitlab.com/gitlab-org/gitlab-ee/issues/9255 and maybe the review can happen as part of that Issue. @sliaquat do you feel it would be beneficial to create a separate test plan?
How will this interact with areas that only use token authentication such as RSS feeds?
Given we have now moved the access checks in to a new Issue, it seems reasonable that this Issue should cover adding the setting and the UI flow to enable it?
@lmcandrew@jamedjo just to clarify this. Do we want a feature flag AND a UI setting to enable this? :)
just to clarify this. Do we want a feature flag AND a UI setting to enable this? :)
@jameslopez That way having the flag fully enabled would give everyone the option to enforce SSO or keep things as they are. Until the feature is mostly functional the setting would only be visible if the flag had been enabled for that group.
I see if after the SAML dance a user does not have an active session, they are redirected to login/register. Does this mean if I don’t have an active session, I would SSO into my group and then be prompted to enter my GitLab username/password?
My original diagram reflected the highlighted branch in the activity diagram as branching based on "No active session" / "Active session". I've updated this to "linked user" / "no linked user":
The idea there is to check for a corresponding user linked to that particular group. If not found, we need to establish that link and route to the login/registration page. Once that link has been established, we don't need to present the login/registration page and can simply present the requested resource.
The desired state is to make sure we're not constantly presenting the user with the login/registration page. Once that user's identity has been linked to the group, there shouldn't be a need to do this after they've successfully SSOed in.
There might be an issue here where a user hasn't linked a user to the group, but has an active session on GitLab.com.
What if I don't want to link my current user to the group? I don't know if it makes sense to establish the link without the user providing some input on which set of credentials they'd like to use. What if we:
Log the user out (do we need to do this?),
Present the sign-in/registration page,
Present a banner that reads "Register or log in with the account you'd like to access {GROUP_NAME} with."
My original diagram reflected the highlighted branch in the activity diagram as branching based on "No active session" / "Active session". I've updated this to "linked user" / "no linked user"
In the code we branch first on if current_user. If there is a user we attempt to link unlinked users, and then proceed to update memberships. If there isn't a current_user we follow the sign_in_user_flow where we try to find a user from an identity link and update memberships, before setting the SAML session details and signing the user in. 2FA might complicate things there.
I'll try and compare that to the diagram:
When there is no linked user but the user is signed into gitlab we can establish a link without redirecting them anywhere.
Linked user not signed into gitlab: 'Create session' creates both a GitLab session and stores SAML session details
'Map user to group': the GroupSaml#MembershipUpdater gets called in multiple places, but has no affect if the user is already a member of the group. If this is later expanded to do more complicated membership syncing then that means things can also get updated when a linked user re-authenticates or when a current_user signed into GitLab first links their account.
What if I don't want to link my current user to the group?
Visiting the /sso link would have shown the account link warning, so at this point we could include details about which account is currently active to give the user an opportunity to sign out.
We could also present a confirm link page when returning from SSO before linking the account This might not be simple to build, but could be written in a similar way to the 2FA page.
If there isn't a current_user we follow the sign_in_user_flow where we try to find a user from an identity link and update memberships, before setting the SAML session details and signing the user in.
I think this is the bit that's still a little confusing to me. Is the sign_in_user_flow creating a session without presenting users/sign_in if there's an existing identity link? If not, it seems to conflict with the work in https://gitlab.com/gitlab-org/gitlab-ee/issues/6261.
Visiting the /sso link would have shown the account link warning, so at this point we could include details about which account is currently active to give the user an opportunity to sign out.
We could also present a confirm link page when returning from SSO before linking the account This might not be simple to build, but could be written in a similar way to the 2FA page.
Sure, this makes the most sense to me. I think another issue around this might be helpful - we can do the simplest/most boring thing for now, which would probably be establishing the link on current_user. We can consider the confirmation link page for a future iteration. I'll create this
Hi @jeremy - question from a customer regarding this upcoming feature which is currently behind the feature flag:
Also, I’m still exploring, but I would expect us to be able use subgroups and still have SAML enforcement with them as well. I saw a strange behavior where I wasn’t able to change someone’s permission on a subgroup without the “SAML” tag disappearing, so I’m hoping this is just a symptom of the “enforcement of SAML” not being active yet.
Can you please clarify if subgroups will have that enforcement once this feature goes live? Thanks!
@jeremy@aolson yes I have it working with Okta. Users were only able to get to the groups with SSO if they had been added via Okta. I did the following tests:
Added existing gitlab users to Okta
Users were now able to access the GitLab Group with Okta SSO and log in from the Okta UI
Ping if you have specific questions and I can test out any other flow.
But if the user then logs off of Okta and Gitlab.com completely, are they then still able to get access to the same private groups with ONLY their Gitlab.com credentials? That is what I am experiencing.
In other words, it seems to enforce SSO only for the first login, but after the first login, users can simply authenticate using Gitlab.com credentials. Can you please test that?
Note: Partial SSO enforcement was introduced in 11.8. With this option enabled, users must use your group’s GitLab single sign on URL to be added to the group or be added via SCIM. Users can no longer be added manually. After a user has been added to the group, GitLab does not continue to enforce the use of SSO, but we’ll add a persistent check in a later version.
Perhaps the "Enforce SSO-only authentication for this group" verbiage for this feature should be change to "Enforce SSO-only for initial addition of users to this group".
The obvious limitation here is if a user leaves the company (and is deactivated from our Okta SSO system), they still have access to the code until we manually remove them from gitlab.com. Also we can't limit from where they access the code because we can't leverage our Okta SSO policy mechanisms. All of this was available to us with the Githost.io version of GitLab.
Are there APIs available for us to at least query the gitlab.com system for active users so that I can then query them against their status in our SSO system?
Thanks for your feedback @tyson.malik - I agree the text could better describe the current behaviour. We made the decision to ship an early version of this feature (with some known gaps), so we could get feedback and faster iterate on what has been implemented so far.
Are there APIs available for us to at least query the gitlab.com system for active users so that I can then query them against their status in our SSO system?
SAML SSO enforcement is only enforcing SAML SSO for initially adding a user to a group. But afterwards, they don't have to use SAML SSO (e.g. Okta). They'll still have access to the group with their non SAML account.
Hi @cynthia I'm currently working to clarify, the customer just pinged today about the issue. I was actively looking for documentation to see if this is active for on-prem. Apologies if the tag was premature.
@yofeldstein ah, this issue is specifically for Group SAML which is .com only. I believe we had an issue about merging the two features so it's more consistent, but I recommend reaching out to ~"group::access"