Geo proxying with different URLs may break SAML authentication

Summary

When using Geo proxying with different URLs (the default for Geo on 15.1), logins may break on the secondary sites, as it will redirect to SAML instead of to the primary site.

This was reported on in a support ticket (internal), where the customer provided some extra information they gathered while troubleshooting this. They observed that the AssertionConsumerServiceURL (ACS URL) in the SAML request from the Geo secondary had the secondary site's URL, instead of the primary's. As some SAML providers (such as the one used by the customer, FortiAuthenticator may require that the ACS URL matches a particular value, and it no longer is the same as the primary, this may have caused the issue. The individual I was collaborating with does not have control over their SAML IdP settings, so they were not able to try changing this configuration. GitLab team members may view the ticket for more information and context on the customer's case.

Steps to reproduce

  1. Have a Geo configuration with different URLs on a GitLab version older than 15.1.
  2. Make sure SAML is configured. It may require configuring a strict ACS URL.
  3. Upgrade to GitLab 15.1, which enables Geo proxying by default.
  4. Attempt to sign in on a Geo secondary.

What is the current bug behavior?

Signing in on the Geo secondary redirects to the SAML page.

What is the expected correct behavior?

Signing in on the Geo secondary redirects to the primary site's login page.

Relevant logs and/or screenshots

GitLab team members may view the support ticket.

Workaround

Disable Geo proxying.

Possible fixes

  • Would it make sense/is it feasible to change the ACS URL that is returned?
  • Should we revert the change which made Geo proxying the default for different URLS?
  • Perhaps we just need more documentation.