docs: Correct the Group SSO redirect for Minimal Access users

What does this MR do?

Corrects the Group SSO sentence in "Minimal access users receive 404 errors". A Minimal Access user signing in with Group SAML has been redirected to the groups dashboard, not the parent group page, since GitLab 17.7.

Why

!172226 (merged) ("Route minimal access user to groups dashboard", milestone 17.7) changed ee/app/controllers/groups/omniauth_callbacks_controller.rb. When the SAML sign-in target is the group path and the user cannot read_group, the redirect goes to dashboard_groups_path:

path = saml_redirect_path

# Ensure that if redirecting to the SAML group path, check the user has access first.
if path == group_path(@unauthenticated_group)
  path = safe_group_path(@unauthenticated_group) || dashboard_groups_path
end

That code is current on master, and the spec the same MR shipped pins the behaviour in ee/spec/controllers/groups/omniauth_callbacks_controller_spec.rb, under "when user has minimal access to the group":

• No RelayState: redirects to dashboard_groups_path.
• RelayState set to the group path: redirects to dashboard_groups_path.
• RelayState set to another page: redirects to that page.

The second case is the one the current wording describes. The page says the user "receive[s] a 404 error immediately because they are redirected to the parent group page", and the spec asserts that even when the relay state points at the group, they land on the dashboard.

The standard web authentication case is unchanged, so that sentence and the link to #267996 stay. Only the Group SSO sentence moves.

The replacement sentence describes a sign-in that targets the group, which is the flow this section is about. A RelayState pointing elsewhere takes precedence, and that felt like more detail than a permissions page needs. Say if you would rather it were stated.

@bbodenmiller raised this in #267996 in December 2025 and it has not been answered. The groups dashboard has its own open issues, #506280 and #507968, so the replacement text links them.

Testing

The behaviour is pinned by ee/spec/controllers/groups/omniauth_callbacks_controller_spec.rb, which runs in CI on every pipeline. I have not exercised a Group SAML sign-in myself; the three cases above are read from that spec and from the controller on master.

Related issues

Related to #267996 Related to #506280 Related to #507968

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

AI-Generated Content Disclosure: This MR was prepared with assistance from Claude Code. The output has been reviewed for correctness, verified against source, and validated against the documentation style guide.