Fix: skipSslValidation ignored when fetching SAML IDP metadata during login #3971
Open
duanemay wants to merge 2 commits into
Open
Fix: skipSslValidation ignored when fetching SAML IDP metadata during login #3971duanemay wants to merge 2 commits into
duanemay wants to merge 2 commits into
Conversation
…efault trust store doesn't trust
…ogin The live SSO login path (ConfiguratorRelyingPartyRegistrationRepository / SamlRelyingPartyRegistrationRepositoryConfig) built relying party registrations by handing the IDP's metadata URL straight to Spring Security's RelyingPartyRegistrations.fromMetadataLocation(), which fetches over a raw HttpsURLConnection using only the JVM's default trust store. That path completely ignored the per-IDP skipSslValidation flag, unlike the admin validate path (SamlIdentityProviderConfigurator.configureURLMetadata), which correctly honors it via FixedHttpMetaDataProvider. This let an IDP validate/save successfully while every actual login failed with SSLHandshakeException/PKIX path building errors whenever the IDP's metadata endpoint used a certificate the JVM didn't trust. Extract SamlIdentityProviderConfigurator.resolveMetadataXml(), which fetches URL-type metadata through the same skipSslValidation-aware, caching FixedHttpMetaDataProvider used for admin validation, and route both the DB/API-managed and bootstrap-YAML login paths through it instead of handing a raw URL to Spring Security. This also picks up FixedHttpMetaDataProvider's cache, so login no longer performs a live metadata fetch on every SSO redirect. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes SAML login failures for IDPs whose metadata URL uses an untrusted TLS certificate by ensuring the live login metadata fetch path honors the per-IDP skipSslValidation flag (reusing the same FixedHttpMetaDataProvider behavior as the admin validation path).
Changes:
- Route relying-party registration building through
SamlIdentityProviderConfigurator.resolveMetadataXml(...)so URL metadata is fetched withskipSslValidationsupport and then parsed as literal XML. - Refactor
SamlIdentityProviderConfiguratorto exposeresolveMetadataXml(...)and reuse it for the URL-metadata path. - Add an HTTPS integration-style test that exercises a self-signed metadata endpoint and asserts login-path registration succeeds when
skipSslValidation=true.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| server/src/main/java/org/cloudfoundry/identity/uaa/provider/saml/SamlRelyingPartyRegistrationRepositoryConfig.java | Uses configurator metadata resolution so skip-SSL behavior is honored when building registrations. |
| server/src/main/java/org/cloudfoundry/identity/uaa/provider/saml/SamlIdentityProviderConfigurator.java | Introduces resolveMetadataXml(...) and reuses it for URL metadata handling. |
| server/src/main/java/org/cloudfoundry/identity/uaa/provider/saml/ConfiguratorRelyingPartyRegistrationRepository.java | Switches metadata input from raw location to resolved XML to avoid Spring’s direct URL fetch behavior. |
| server/src/test/java/org/cloudfoundry/identity/uaa/provider/saml/ConfiguratorRelyingPartyRegistrationRepositoryTest.java | Adds a test covering self-signed HTTPS metadata with skipSslValidation=true. |
Comment on lines
+161
to
165
| public String resolveMetadataXml(SamlIdentityProviderDefinition def) { | ||
| if (def.getType() != SamlIdentityProviderDefinition.MetadataLocation.URL) { | ||
| return def.getMetaDataLocation(); | ||
| } | ||
| try { |
Comment on lines
+395
to
+398
| // The metadata endpoint presents a self-signed cert the JVM does not trust. | ||
| // skipSslValidation=true should make UAA trust it here too, just like it does | ||
| // on the admin validate path -- today it does not, because the live login-path | ||
| // fetch (RelyingPartyRegistrations.fromMetadataLocation) ignores skipSslValidation. |
Comment on lines
+401
to
+403
| } finally { | ||
| httpsServer.stop(0); | ||
| } |
cf-foundation-community-automation
Bot
moved this to Inbox
in Foundational Infrastructure Working Group
strehle
reviewed
Jul 4, 2026
strehle
left a comment
strehle
left a comment
Member
There was a problem hiding this comment.
this skipssl for SAML metadata was alway a problem to me. In our landsapes we dont allow the automatic update but provision SAML metadata with API ... in the rare use cases.
We may allow the custom trust achor - as discussed - so do you really want it back ?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
SAML login fails with:
org.springframework.security.saml2.Saml2Exception: Unable to build SAML relying party
registration for:
Caused by: javax.net.ssl.SSLHandshakeException: (certificate_unknown) PKIX path building
failed: unable to find valid certification path to requested target
...for SAML IDPs whose metadata endpoint uses a certificate the JVM's default trust
store doesn't trust (self-signed, internal CA, etc.) — even when the IDP is
configured with
skipSslValidation: true.Root cause
UAA has two separate SAML metadata-fetch code paths:
SamlIdentityProviderConfigurator.configureURLMetadata→FixedHttpMetaDataProvider) — correctly honors the per-IDPskipSslValidationflagand caches results.
ConfiguratorRelyingPartyRegistrationRepository→RelyingPartyRegistrationBuilder→ Spring Security'sRelyingPartyRegistrations.fromMetadataLocation()) — does a rawHttpsURLConnectionfetch on every SSO redirect, using only the JVM's default trust store, and
completely ignoring
skipSslValidation.This means an IDP can validate/save successfully in the admin UI/API but fail on every
actual login.