You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Fix IAS proof-token validation regression under Istio / Kyma with credential-type: X509_GENERATED
SapIdJwtSignatureValidator was setting the x-client_cert request header directly from X509Certificate#getPEM(). When the certificate originates from Istio's x-forwarded-client-cert (XFCC) header, the PEM includes -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- delimiters and CR/LF line breaks
Since 4.0.0, the token-client HTTP transport uses Java 11's HttpClient, which enforces RFC 7230 and rejects any header value containing CR/LF with IllegalArgumentException (surfaced as "Token signature can not be validated because: invalid header value: <PEM>"). Every authenticated request behind Istio failed proof-token validation as a result
The header value is now sanitized to bare base64-encoded DER (PEM delimiters and all whitespace stripped) before being placed on the wire. The IAS JWKS endpoint accepts this form. A new X509Certificate#getLeafCertificateAsHeaderValue() accessor keeps the sanitization next to the PEM parsing; getPEM()'s existing contract is unchanged
JavaHttpClientAdapter additionally fails fast with a message naming the offending header key (not the value, which may be sensitive) if a header value ever contains CR/LF, turning any future regression from a misleading "invalid header value: <PEM>" into an actionable transport-layer error
Update dependencies:
Spring Boot: 4.0.6 → 4.1.0
Spring Framework: 7.0.7 → 7.0.8
Spring Security: 7.0.5 → 7.1.0
Jetty: 12.1.9 → 12.1.10
Reactor: 3.8.2 → 3.8.6
JUnit: 6.0.3 → 6.1.0
SpotBugs annotations: 4.9.8 → 4.10.2
SpotBugs Maven Plugin: 4.9.8.3 → 4.10.2.0
org.json: 20251224 → 20260522
logcaptor: 2.12.2 → 2.12.6
assertj-core (samples): 3.24.2 → 3.27.7
maven-surefire-plugin: 3.5.5 → 3.5.6
jacoco-maven-plugin: 0.8.14 → 0.8.15
central-publishing-maven-plugin: 0.10.0 → 0.11.0
Fix junit-bom import in the root pom — entry was missing <type>pom</type><scope>import</scope>, so JUnit platform/jupiter versions were silently resolved through Spring Boot's BOM. Now correctly imported and ordered ahead of spring-boot-dependencies so junit-bom wins for all JUnit 6 artifacts.