Skip to content

Fix 500 error for domain verification

What does this MR do and why?

Describe in detail what your merge request does and why.

Fixes #412343 (closed)

Fix 500 error for domain verification

When SSO is enforced and a top-level group owner attempts to add a domain for verification, a 500 error can occur if the user does not have an active SSO session. This change will cause the user to be redirected to SSO sign-in in the absence of an SSO session.

The only reason owners are exempted from SSO at the top level is to ensure they don't get locked out in the case of an SSO configuration error. Longer term we may want to enforce SSO for all top-level group endpoints except the main group page and SSO settings, specifically. This would prevent these types of issues from occurring and would be more secure.

This only protects the index and new actions. This is partially because GET requests are safer to intercept - no chance of in-flight data loss if, for example, we redirected to SSO authentication while trying to create a new domain, and because this should reasonably address the paths to creating a new domain.

This feature is behind a feature flag just in case something doesn't work as expected.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Enable the feature flag: `Feature.enable(:domain_verification_sso_redirect)
  2. Have Group SAML SSO configured. See GDK docs for help. You can also use an Okta Dev account. Be sure to enable SSO enforcement.
  3. Simulate SaaS using GITLAB_SIMULATE_SAAS=1 gdk start and also set GitLab to check namespace plan.
  4. Ensure test namespace has a Premium or Ultimate plan.
  5. Navigate to the Group -> Settings -> Domain Verification
  6. Observe that you should be redirected to SAML SSO sign in if you don't already have an active SSO session.
  7. After successfully signing in you should be redirected back to your previous location - either Domain Verification index page or the new domain page.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Drew Blessing

Merge request reports