Summary:

I'm encountering an issue with the SAML plugin in our Jenkins instance which uses two different URLs to access it (from a human-facing side and from a backend/robot side).

I'd like to know if it's possible to be able to present a different Jenkins URL in the /securityRealm/finishLogin string that's part of the SAML metadata (at JENKINS_URL/securityRealm/metadata), from the JENKINS_URL which is defined globally i Jenkins config.

Background:

We have a setup where our Jenkins is hosted internally, and defines its JENKINS_URL (via standard system config) as https://internal-jenkins.internal.domain

For humans to access it, they go through a (company-wide) Beyondcorp-type proxy which uses a public URL like: https://internal-jenkins.public.domain. This proxy is used to gate access to both external SaaS type platforms and pass through SSO, and also to internal systems. So internally, that proxy routes to it via https://internal-jenkins.internal.domain.

Other backend services also talk to Jenkins and handle parsing the Jenkins URL in various responses and build metadata, and so this is why we have continued to leave JENKINS_URL defined as the https://internal-jenkins.internal.domain (internal version).

Details:

I get an error like this:

Assertion consumer service with destination https://internal-jenkins.public.domain/securityRealm/finishLogin could not be found for spDescriptor org.opensaml.saml.saml2.metadata.impl.SPSSODescriptorImpl@6fe1e10e

..which seems to be because, when I look at /securityRealm/metadata, that defines the ACS Location listed as the internal form (which corresponds to our JENKINS_URL).. and this is not the same internal-jenkins.public.domain URL that humans can take to access Jenkins.

I'm finding that the only way I can get SAML to work is by changing the JENKINS_URL to the public  "https://internal-jenkins.public.domain" form, at which point the assertion XML sets the proper human-facing https://internal-jenkins.public.domain/securityRealm/finishLogin. However, changing our JENKINS_URL to this will break a lot of our integrations and so is a nontrivial migration to do.

I am wondering whether, for example, in the SAML metadata element:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://internal-jenkins.internal.domain/securityRealm/finishLogin" index="0"/>

There is a way to manually configure the URL used for `Location` and instead be able to change it to https://internal-jenkins.public.domain/securityRealm/finishLogin, since this is the URL that users actually see.

I did look at the https://github.com/jenkinsci/saml-plugin/blob/main/doc/TROUBLESHOOTING.md#no-valid-subject-assertion-found-in-response doc and see I can override the URL but in the SP Entry ID, not in other components of the SAML assertion.

It's also not really feasible for us to change all human access to the internal-jenkins.public.domain form, because we have hundreds of users and it would move us away from this beyondcorp strategy altogether.

I'm not super experienced at SAML so I hope I've been able to explain the problem well enough, thanks for your patience and time!