Add audit event and logs for SCIM provisioned users from unverified user auto-deletion.
In order to reduce the number of support requests where users may inadvertently create an account that they cannot verify (e.g email typo) we introduced the auto deletion of unverified users Automatically delete unverified unconfirmed use... (#352514 - closed). Currently set at 3 days, it makes sense for most scenarios except SCIM provisioned users where organizations often provision them ahead of time (few days to few weeks) such as when onboarding new employees.
Based on our discussion, it was suggested to exclude SCIM provisioned. accounts from this deletion. To identify such users we can use the provisioned_by attribute or add a new field.
Possible workaround
In the meantime, we recommend SaaS customers to verify their domain, which bypasses confirmation.
Proposal
Implement a 30 day exemption from auto-deletion for SCIM provisioned users. Based on the following discussion, we will add an audit event and logs to indicate when a SCIM provisioned users is deleted via the unverified accounts worker. This is applicable to users not currently adopting enterprise users.
Designs
Relates to
Activity
added devopsmanage sectiondev labels
mentioned in issue #423082 (closed)
added Support Efficiency label
changed milestone to %Backlog
marked this issue as related to #423082 (closed)
Linking this comment here so it doesn't get lost:
Since we're no longer going to be using it for Enterprise User definition, and I'm not aware of it being used for anything else, I don't think we would need to use a new db field? We could in theory change when
provisioned_byis applied.-
@cynthia I see that this already has the Support Efficiency label. I am open to this issue either following our normal process for Support Efficiency , or getting pulled into a milestone sooner if we have more issues about it. AFAIK, we've only had one customer mention this so far. If it continues to be an issue, will you ping me and we can get it in?
@hsutor certainly. We have quite a few Support Efficiency issues so I try to go through them every milestone. Mostly, I let these go through the normal process, or if it really becomes a "problem", move it "up" as a Support Priority.
added devopsgovern sectionsec labels and removed devopsmanage sectiondev labels
changed milestone to %16.6
@hsutor @cynthia Should we consider having some sort of expiry on SCIM users even if it's much longer? Theoretically a malicious group could configure SCIM and assign any user/email address they want and those users would be created and potentially held indefinitely.
Realistically, given our new definition for enterprise users, it wouldn't really be much of a risk - a user could later come and perform a password reset and use their account despite being linked to SCIM. But it could create a less than desirable user-experience to have to go through the password reset. Especially if they don't remember ever signing up.
-
@dblessing agreed. What about 30 days/1 month?
That seems realistic, especially given the solution of using Domain Verification.
Edited by Drew Blessing
added featureenhancement label
added customer label
-
This didn't make Deliverable in our %16.6 planning, pushing out
I can see that this is affecting customers so I'll tenatively schedule into %16.7
Edited by Hannah Sutor changed milestone to %16.7
added groupauthentication label and removed groupauthentication and authorization [DEPRECATED] label
mentioned in merge request gitlab-org/professional-services-automation/tools/migration/congregate!914 (closed)
mentioned in issue gitlab-org/professional-services-automation/tools/migration/congregate#965
-
Did not make Deliverable , moving milestone
changed milestone to %16.8
changed milestone to %16.9
added documentation label
-
Did not make Deliverable , pushing to future milestone
changed milestone to %16.11
added authn FY25 roadmap label
By implementing Automatically delete unverified unconfirmed use... (#352514 - closed) we made a few steps forward in enhancing security. IMO excluding unverified SCIM provisioned users from auto-deletion is one step backward.
We could suggest(1) organizations to set up verified domains to bypass user email confirmation for their users provisioned with SAML or SCIM. Not only will it eliminate this issue for organizations, but also enable automatic claims of enterprise users. That should enhance security further for organizations and provide ability to manage their user accounts. That is why I think this suggestion is not a "workaround" to resolve this issue, but an advice/recommendation/guidance on how to enhance security for organizations on GitLab.com.
I think we should update documentation to better rationale automatic deletion of users and emphasize that it is to enhancing security.
Mention about automatic deletion of users, add the suggestion(1), and rationale[#429285 (comment 1738903477), #429285 (comment 1741413505), #429285 (comment 1742231984)] why automatic deletion applies to unverified provisioned users too in SAML/SCIM guides.
Edited by Bogdan Denkovych
@bdenkovych We had also considered having a longer unverified status period for SCIM provisioned users. This one came from support so I'd ask @alvin on how frequently we see this being an issue? (& whether all those users are able to adopt enterprise user or this is still needed as a standalone feature)
-
I think Alvin is out for a bit. @cynthia would you be willing to chime in here?
-
@hsutor @adil.farrukh I agree with @bdenkovych that for security reasons, it's best to have auto-deletion. Also, really, you don't want an account unverified just sitting around for years.
It may be confusing to users to have multiple rules for auto-deletion, so I'd push for domain verification usage as well. However, I would not be opposed to us having a longer period for enterprise users if there is a demand/concrete use case for it, and it's clearly documented.
It has been a long time but I think we should either close this issue or put it into
Backlogor something...Here is my take:
If an owner of a top-level group implements SCIM on their group, they expect SCIM to be the SSOT for user management on that group - only SCIM should be responsible for creating users and removing users...
In the scenario where the customer has not added domain verification, an enterprise SCIM provisioned GitLab.com user will be automatically deleted after 3 days with no indication whatsoever. This is an unexpected, unlogged and unaudited event on a customer's SCIM managed environment which leads to large amounts of confusion - SCIM logs say user added, but where is the user?
Worse, "stateful" SCIM providers like Azure AD will not re-provision a user since it believes that the user was already successfully provisioned so it has to be done manually by an idP admin.
I would fully agree with Bogdan's recommendation here if we had some kind of audit event that an Enterprise owner could see that clearly said
Unverified user was deletedor something.
-
@alvin I think that's the best trade-off solution in this case, as the main issue seems to be lack of visibility (though I did see a support ticket where they expected to SCIM provision users 1-2 weeks ahead of employee start dates).
I'll modify the issue description for the proposal to add audit event & logs when a SCIM provisioned users is deleted via the unverified accounts path, and we can schedule it for a milestone (should be small effort)
Thanks @adil.farrukh! In this case, I will add this to the Support Team section of the milestone planning issue :-)
mentioned in issue #429285 (closed)
mentioned in issue #440803
changed milestone to %17.2
mentioned in merge request gitlab-org/professional-services-automation/tools/migration/congregate!982 (merged)
removed milestone %17.2
changed milestone to %Backlog
