Skip to content

Bump com.sap.cloud.security.xsuaa:token-client from 3.5.7 to 4.0.8 in /sdm#531

Open
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/maven/sdm/com.sap.cloud.security.xsuaa-token-client-4.0.8
Open

Bump com.sap.cloud.security.xsuaa:token-client from 3.5.7 to 4.0.8 in /sdm#531
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/maven/sdm/com.sap.cloud.security.xsuaa-token-client-4.0.8

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 3, 2026

Copy link
Copy Markdown

Bumps com.sap.cloud.security.xsuaa:token-client from 3.5.7 to 4.0.8.

Release notes

Sourced from com.sap.cloud.security.xsuaa:token-client's releases.

4.0.8

  • 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.

4.0.7

  • Fix multi-tenant XSUAA token exchange in DefaultXsuaaTokenExtension
    • The IAS-to-XSUAA exchange used the provider subdomain endpoint, which caused XSUAA to resolve the provider tenant instead of the tenant carried in the X-zid header (app_tid)
    • Token exchange now targets a tenant-agnostic endpoint built from the uaadomain binding property, so XSUAA resolves the tenant via X-zid
    • For X.509 credentials the host's authentication. segment is replaced with authentication.cert. (analogous to the Node.js library), e.g. authentication.eu10.hana.ondemand.comauthentication.cert.eu10.hana.ondemand.com
    • Falls back to the existing subdomain-bearing endpoint when uaadomain is missing, preserving behavior for legacy bindings

4.0.6

Update dependencies Spring Boot (legacy 3.x modules): 3.5.9 → 3.5.14 Spring Framework (legacy 3.x modules): 6.2.15 → 6.2.18 Spring Security (legacy 3.x modules): 6.5.7 → 6.5.10 Caffeine: 3.2.0 → 3.2.4 SpotBugs Maven Plugin: 4.9.8.2 → 4.9.8.3

4.0.5

  • Restore deprecated HttpClientFactory.services field and ServiceLoader-based factory discovery for backward compatibility

    • Custom HttpClientFactory implementations registered via META-INF/services are discovered again
    • A deprecation warning is logged when a custom factory is used, guiding users to migrate to SecurityHttpClientFactory with SecurityHttpClientProvider
    • Token services with default (no-arg) constructors continue to use the new SecurityHttpClientProvider internally
  • Fix multi-tenant IAS token exchange by adding app_tid parameter to the token exchange request in DefaultIdTokenExtension

    • In multi-tenant applications, IAS requires app_tid in addition to client_id to uniquely identify the application
    • The app_tid is extracted from the incoming access token and included when present

4.0.4

... (truncated)

Changelog

Sourced from com.sap.cloud.security.xsuaa:token-client's changelog.

4.0.8

  • 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#getPEMHeaderValue() 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.

4.0.7

  • Fix mTLS handshake regression in SSLContextFactory
    • Initialize the SSLContext with an explicit TrustManagerFactory backed by the system default trust store instead of passing null, fixing (certificate_unknown) No X509TrustManager implementation available failures observed on certain runtime configurations
  • Add missing no-arg constructor to DefaultOAuth2TokenService
    • The class lacked the no-arg constructor that the migration documentation (token-client/CUSTOM_HTTPCLIENT.md) advertised
    • The sibling services DefaultOAuth2TokenKeyService and DefaultOidcConfigurationService already had it; this restores symmetry
    • The new constructor obtains a SecurityHttpClient via SecurityHttpClientProvider.createClient(null) and delegates to the existing (SecurityHttpClient) constructor
  • Fix multi-tenant XSUAA token exchange in DefaultXsuaaTokenExtension
    • The IAS-to-XSUAA exchange used the provider subdomain endpoint, which caused XSUAA to resolve the provider tenant instead of the tenant carried in the X-zid header (app_tid)
    • Token exchange now targets a tenant-agnostic endpoint built from the uaadomain binding property, so XSUAA resolves the tenant via X-zid
    • For X.509 credentials the host's authentication. segment is replaced with authentication.cert. (analogous to the Node.js library), e.g. authentication.eu10.hana.ondemand.comauthentication.cert.eu10.hana.ondemand.com
    • Falls back to the existing subdomain-bearing endpoint when uaadomain is missing, preserving behavior for legacy bindings

4.0.6

  • Update dependencies to address known vulnerabilities:
    • Spring Boot (legacy 3.x modules): 3.5.9 → 3.5.14
    • Spring Framework (legacy 3.x modules): 6.2.15 → 6.2.18
    • Spring Security (legacy 3.x modules): 6.5.7 → 6.5.10
    • Caffeine: 3.2.0 → 3.2.4
    • SpotBugs Maven Plugin: 4.9.8.2 → 4.9.8.3

4.0.5

  • Restore deprecated HttpClientFactory.services field and ServiceLoader-based factory discovery for backward compatibility

... (truncated)

Commits
  • 4a77da7 fix: Sanitize x-client_cert header for IAS proof-token validation (4.0.8) (#1...
  • d588235 chore: Bundle Dependabot updates for 4.1.0 (#1984)
  • b25248c Merge pull request #1976 from SAP/release-4.0.7
  • 5d82f47 Merge branch 'main' into release-4.0.7
  • 6450c9c fix: Initialize SSLContext with explicit TrustManager (4.x) (#1980)
  • d14e1aa Add missing no-arg constructor to DefaultOAuth2TokenService (#1981)
  • cee9f18 Merge pull request #1972 from SAP/bugfix/xsuaa-token-extension-multitenant-ro...
  • 5639c8b refactor: Use UriUtil.expandPath in getUaaDomainTokenEndpoint
  • c90ae22 refactor: Use UriUtil.expandPath in getUaaDomainTokenEndpoint
  • 2863517 fix: Restore spring-boot-starter-parent version in samples
  • Additional commits viewable in compare view

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file java Pull requests that update java code labels Jul 3, 2026
@dependabot dependabot Bot force-pushed the dependabot/maven/sdm/com.sap.cloud.security.xsuaa-token-client-4.0.8 branch from 644b58e to a3a3284 Compare July 8, 2026 04:52
Bumps [com.sap.cloud.security.xsuaa:token-client](https://github.com/SAP/cloud-security-xsuaa-integration) from 3.5.7 to 4.0.8.
- [Release notes](https://github.com/SAP/cloud-security-xsuaa-integration/releases)
- [Changelog](https://github.com/SAP/cloud-security-services-integration-library/blob/main/CHANGELOG.md)
- [Commits](SAP/cloud-security-services-integration-library@3.5.7...4.0.8)

---
updated-dependencies:
- dependency-name: com.sap.cloud.security.xsuaa:token-client
  dependency-version: 4.0.8
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot force-pushed the dependabot/maven/sdm/com.sap.cloud.security.xsuaa-token-client-4.0.8 branch from a3a3284 to abe7703 Compare July 10, 2026 08:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file java Pull requests that update java code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants