We enable organizations to provision users with SAML SSO and SCIM. When the account is created, a user receives an email to confirm their email address. Once they click the link, they see the GitLab login page. These users are expected to use SAML SSO to log into GitLab. It's a confusing experience for users onboarding into GitLab.
Proposal
Could we have a different link where we redirect these users to their Groups SAML login page after their email is confirmed?
Availability & Testing
What risks does this change pose to our availability?
This is a low risk feature to availability as the change would be in the generated email.
What additional test coverage or changes to tests will be needed?
Ensure coverage for existing functionality for email confirmation for normal users. The updated link should only be sent to the SAML/SCIM provisioned users and not regular users.
Will it require cross-browser testing?
N/A
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@lmcandrew We talked this morning about the board being a bit sparse so I'm looking at issues that are fairly small and ran across this one. Will move to %13.9 as a stretch goal.
@mksionek I think @mushakov mentioned that this was an existing request. In any case it should be separate from this email.
We should probably add a setting for the admin to select whether the provisioned users need confirmation or not - it probably depends on their compliance procedures
@lmcandrew Are we planning on working this in %14.2. It looks like this has slipped %14.0 & %14.1 and is getting auto assigned to the current milestone, but no one is actually assigned to it
Hannah Sutorchanged title from Email confirmation link for SAML/SCIM provisioned users to Email confirmation link for SAML/SCIM provisioned users should redirect to provider login
changed title from Email confirmation link for SAML/SCIM provisioned users to Email confirmation link for SAML/SCIM provisioned users should redirect to provider login
An Ultimate customer is facing the same issue and is interested in a resolution that would avoid getting the users into login loops, resetting their passwords and manually linking their accounts. (Internal link)
@mksionek Since you worked on this originally, do you have any insight into how complex this is? It's creating a poor user experience when new customers are setting up their SSO accounts initially.
Hi @hsutor Could a temporary fix be a more verbose banner:
Your email has been confirmed. You can sign in or close this tab.For Enterprise users, refer to the "access granted" email to sign in with Enterprise SSO.
Moving this one back to workflowsolution validation since I don't think we have fully set the direction for implementation here.
@alvin That could be a good MVC, but I wonder if most users even know if they're an "Enterprise User" or not. From what I know so far, that's a flag we have behind the scenes for users who were provisioned. I don't think we make much public reference to what that means or how a user would even know if they're an Enterprise user.
Let's see what it would take to fix this the whole way...meaning:
Newly provisioned user gets confirmation email link
This email link takes them to their provider for login, not the GitLab login page.
I also wonder how this will work because most of our customers don't even want to send confirmation emails for their enterprise users. So is this even worth the effort?
@hsutor thanks for the ping. I agree that putting in the efforts to allow confirmation email bypass (skipping this process altogether) will be the better solution to focus on.
If we do move forward with it. The smallest interation might be to just remove the "Please sign in." part of the message? It's implied and for SSO users, they're likely to know they should sign in from their SSO.
I agree that domain verification, which would remove the need for confirmation emails, is the most elegant and user-friendly solution. But unless we're going to require that path, it's probably still worthwhile to implement an enterprise-user specific confirmation email.
It may not be super difficult at all. We can probably make the current confirmation email template recognize the provisioned_by_group_id parameter and adjust accordingly.
If that's the case this wouldn't be more than a 2.
Education/Ultimate user here - We also have the same issue (https://support.gitlab.com/hc/requests/322335). We are about to roll out GitLab to around 700 users (moving from an on-prem system) and are worried about unnecessary support calls this will generate.
Why interested: Currently users fall into the trap of clicking a link in the email confirmation, which leads them directly to the GitLab.com login page, rather than to the customer SSO Login page. People tend to then fill in credentials in the GitLab login screen which is a potential security leak.
Current solution for this problem: The fix to bypass email validation for SSO accounts is a work-around that solves part of the problem.
Enterprise premium (customer) looking for this feature. This particular customer has had issues in the past with our IP block implementation and it is believed that this change will drastically help minimize incorrect login attempts into their SaaS namespace.
@hsutor considering this hasn't been assigned, what do you think the likelihood is of it bumping out again?
Why interested: Wants to avoid users entering their credentials into a third-party system (GitLab.com); as well avoid confusion and frustration while onboarding users to GitLab
Current solution for this problem: None; the workaround using Domain verification is considered insufficient
Impact to the customer of not having this: Confusing and frustrating onboarding experience for their users; security concerns
Questions: This is currently in 15.8, but as mentioned above likely to get bumped again and has been for a while now. Is the workaround with Domain verification considered the solution for this problem?
The sales team is working with this large Canadian prospect on a GitLab SaaS Ultimate deal with commit for Q4. They have recently implemented SSO with SCIM for gitlab.com. They have run into the problem that is documented in this issue. We are aware of Certified Domains as a possible solution and looking into that as a workaround also.
Prospect is less than pleased about how this works today and would really like to see a quick resolution.
What are the concerns:
user onboarding experience will be impacted (after email confirmation the user is not directed back to the SSO page - this could impact internal support during roll out)
Prospect has read through this issue - it has been open for a long time and keeps getting pushed. Presently they are a customer with a competitor (A...). With their current vendor they have seen requests for fixes go into a black hole. They are concerned this could be the case here... They do like our transparency and it is a key consideration for why they are considering GitLab.
Their team having to create workaround processes for a smooth onboarding of new users.
We are expecting their deployment to start in Feb 2023.
So what is the ask?
Prospect is asking we push priority for a fix with the software pointing back to the SSO provider after email verification (maybe we are thinking this is simple but in reality harder to implement??).
@adil.farrukh I double checked with the prospect - they are NOT using Verified Domains.
Also, just want to make sure we are focusing on the current behavior - discussion thread is focused on my comment from Jan 5, 2023. That problem has been resolved but morphed into behavior i documented below - see my note from April 12
@adil.farrukh We had originally budgeted 5 for service accounts. I'd like to take 2 from that 5 for this issue, if you think that's OK? And mark this one Deliverable for %15.9
@hsutor Are we still looking good for this to be released in 15.9? Important given our conversation a couple weeks ago with the large Canadian prospect. (notes above for reference also)
Now, after a SSO or SCIM provisioned user confirms their email address via the confirmation link, they will be taken to the SSO login page for their specific provider. The MR description contains a screenshot showing this.
@hsutor For this customer (note above) after the fix we made their behavior has morphed to:
We've enabled SAML SSO with SCIM to auto-provision new users in our Github SaaS instance.
However, when we add a new user in through Azure AD, the users are running into issues confirming their account.
They are receiving TWO different-but-sort-of-the-same "Welcome to Gitlabs" emails.
Both emails contain a "confirm your account link" that directs our users to an email confirmation web-page that displays the message "1 error prohibited this user from being saved: Emails was already confirmed, please try signing in"
The page does have a line at the bottom that reads "Already have an account? Sign in"
The Sign in link in the above message re-directs our enterprise users to the public gitlab sign-in page, when it should go to our Gitlab SSO login page.
The page also offers to a resend confirmation instructions if the user enters their email address in the provided box.
If our users enter their email address, and select Resend, they do not receive any new confirmation instructions in their inbox.
One (of the two) original "welcome to gitlab" emails does contain a link to our Enterprise Gitlab SSO login page - if our users manage to find and click it, they can login successfully.
@ronkoster Apologies, I clicked on the link, and incorrectly asked in the thread above (though the question was still valid). I don't see a change within !112112 (diffs) that should result in that behaviour. @dblessing thoughts? would it help to verify SCIM configuration to make sure the id/external_ids are setup correctly and users aren't being duplicated?
@adil.farrukh I do have some screen shots that I can provide via dm. Hesitant to provide that here given the open access nature of the issue. Let me know if that might help.
@adil.farrukh@ronkoster There may potentially be several recent changes that could have impacted this. I'm aware of groupanti-abuse work with email verification, and also a while back we added a feature so that organizations that have verified domains can skip email confirmation.
We should test our flows to see what the current behavior is and then adjust accordingly. The two main permutations I can think of would be with and without a verified domain. I will comment on the internal issue with more thoughts.
Why is this closed? Where is the solution? It seems I still need to verify email domains even when the entire IDP is external and SCIM is used. Additionally, requiring the dedicated GitLab custom domain to match the user's email domain is impractical, especially when customer IDP's manage users from different domains. Why should GitLab enforce email verification for externally managed user accounts that have already undergone verification by external IDP? As a customer with multiple service providers, it’s challenging to verify twice (in gitlab again) domains for all email domains of IDP-registered user accounts. When I use SCIM, email verification should either be trusted as already completed by the SCIM client or at least be optional (sow you can switch it of together with scim provisioned identities).
Is there a follow up of this issue? How can we we add "any " domain as email verified domain to gitlab? @dblessing
Why shall we at all need a dedicated gitlab email verification when using SCIM where identities are managed external? @hsutor@Heddy2022
@fabian.wallwitz1 This issue was around ensuring the confirmation emails contain the correct link to an org's provider. That was added via SSO-provisioned users redirect to provider logi... (!112112 - merged) but I think your question is around not requiring email confirmation to begin with for users that are provisioned by SCIM without having to verify an email domain. Is that understanding correct?
My understanding was that SCIM provisioned accounts were exempt from verification, but I can find more about that if the above assumption is correct.
GitLab still requires email verification for SCIM and SAML users, except when using Domain Verification, because there is no way for GitLab to verify/trust the data from the external IdP. A malicious person/entity could configure SAML/SCIM and put any email addresses into that IdP that they wish. This includes when using something like Azure/Entra ID. The only way to trust that IdP is to verify domain ownership and then trust email addresses in that domain from the IdP.
This answer does not make sense for me. If I configure saml auth in a dedicated gitlab instance via switchboard as admin I expect that gitlab can trust thus configured Idp and its email verification (at least as an option). Additional with scim I verify user identities (including already verified emails) of this External Idp are provisioned by idp and are trustable. Also here only instance admins are able to configure this.
If the admin account would be hacked ( is that the scenario you have in mind?) the email verification by user is the least problem and won‘t prevent to hijack auth cfg at all.
So how shall that make anything more secure?
Trust in Configured IdP: When SAML or SCIM authentication is configured by a GitLab instance admin, GitLab should be able to trust the external IdP's email verification.
@fabian.wallwitz1 Thanks for clarifying. We were responding based on GitLab.com in the context of this issue. GitLab Dedicated definitely changes the conversation. Yes, in a self-managed or Dedicated instance, email confirmation should be optional based on the needs of the organization.
Based on some internal conversations it sounds like instance SCIM may not auto-confirm users/respect the instance email confirmation configuration. We will open a new issue to discuss and address that concern.
I heard for dedicated it's solved already by feature. Maybe documentation for dedicated is not part of the existing docs or missing still.
In General Settings : "Off - New users can sign up without confirming their email address"
Independent of dedicated i also thing SCIM provisioned users - on setups for SAS and EE - to support this switch off notification by and option per user on SCIM- is useful as well.