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 compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

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 added dependencies Pull requests that update a dependency file java Pull requests that update java code labels Jul 3, 2026
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