Revert group SAML extern_uid trust changes

What does this MR do and why?

This MR reverts commit d593d858, the security change that made PATCH /groups/:id/saml/:uid mark a group SAML identity as untrusted (trusted_extern_uid set to false) whenever a group Owner changed its extern_uid. That change also blocked untrusted identities from SAML single sign-on until the user re-linked, and sent a notification email. This behavior shipped in GitLab 18.10 through 19.3.

We are reverting it because the control did not achieve its goal:

  • A group Owner already controls the group's identity provider (IdP) and can assert any NameID through it, so blocking a manual extern_uid change in the API prevented nothing.
  • The re-trust path (re_trust_identity) restored trust automatically whenever the asserted NameID matched the stored one, so the block was independently bypassable.
  • It broke the endpoint's actual purpose, which is to help migrate NameIDs. Every linked user had to re-link before they could sign in again, even during normal, legitimate migrations.

This MR is now a full revert of d593d858, split into two commits: the code revert, and a documentation update.

Per feedback on this MR, we are also removing the saml_extern_uid_changed_email notification entirely (the mailer method, its HTML and text views, its locale strings, and its specs). That email was introduced by the same security change. Now that the sign-in block is gone, there is nothing for the recipient to act on, so the email no longer serves a purpose.

All specs added by the security change are removed along with it: the identity linker spec contexts, the group SAML user spec context, and the provider identity API spec examples. The affected spec files return to their pre-security-change state.

Documentation updates:

  • doc/development/authentication.md no longer mentions trusted_extern_uid, since it is an internal attribute. Three guardrail and model bullets that referenced it are removed.
  • doc/api/saml.md gets a history note stating that, as of GitLab 19.4, updating extern_uid no longer marks the identity as untrusted or sends an email notification.

The post-deployment data migration that re-trusts the rows affected by the security change has moved to a separate follow-up MR, per review feedback: !253640 (merged). This MR contains no database changes.

Closes #608236 (closed).

The discussion and agreement to revert this behavior are recorded in confidential security issue 605704 in gitlab-org/gitlab (GitLab team member access required). For public context, see #227841 (closed).

References

Note for reviewers

.ai/principles/distilled/authentication.md is auto-generated from the authentication documentation and still reflects the old rules until the next distiller run picks up this change. Because of that lag, AI-assisted review may incorrectly flag this MR as reintroducing a vulnerability. That flag would be based on stale, auto-generated guidance rather than the current, agreed-upon direction described above.

Test plan

The four spec files affected by this revert pass locally:

  • ee/spec/lib/gitlab/auth/group_saml/identity_linker_spec.rb
  • ee/spec/lib/gitlab/auth/group_saml/user_spec.rb
  • ee/spec/requests/api/provider_identity_spec.rb
  • spec/mailers/emails/profile_spec.rb

MR acceptance checklist

This is a revert of a previously shipped security change, with no database changes and no new behavior beyond what existed before GitLab 18.10. The checklist below has been considered with that in mind.

Evaluate this MR against the MR acceptance checklist.

Edited by Smriti Garg

Merge request reports

Loading
Loading