Allow SCIM to re-link to an existing account for Enterprise email domains
Background
As an Enterprise SaaS tenant with SAML SSO and SCIM, if I block access to a user via my identity provider (IdP), a SCIM de-provisioning request removes the user from my namespace, and removes the SAML link for that user. The GitLab account is not removed.
If I then re-add the same user to the GitLab app in my IdP, the provisioning flow cannot create the user [as a GitLab account tied to that email address already exists] and the only way for that person may regain access to their GitLab account is to log in to GitLab. This is necessary, as by logging into GitLab directly, the user is proving their ownership of the gitlab account, either by providing a correct password, or following the password reset flow and proving their access to the email address associated therewith.
The above is an important flow, as without it, I could create a SAML SCIM provider and assert ownership over arbitrary accounts (i.e. anyone could create a SAML assertion claiming ownership of sytses@gitlab.com
for example).
Problematically- for most enterprise users that only use GitLab via an IdP such as Okta, it's very likely they may not have ever set a password on Gitlab, and may not even separate the concept of logging into GitLab, from logging into their IdP and clicking the app. This makes for a confusing experience.
Proposal
For an Enterprise Customer (i.e. the owner of a SaaS namespace) managing Enterprise Users (i.e. an account who's primary email is part of a corporate domain), the assertions of my trusted IdP could be allowed to automatically re-link to an account with a matching email.
I believe this would be possible at the API level with #227841 (closed), but that issue doesn't quite address this scenario as the account in question would not be part of the group.
Current Workaround
For a user attempting to re-gain access to a SaaS namespace, they must log into GitLab (resetting their password if not known) and manually link with their IdP.