Skip to content

Releases: SAP/cloud-security-services-integration-library

4.0.8

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 03 Jul 07:29
4a77da7
  • 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

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 22 Jun 09:33
  • 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

3.7.4

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 22 Jun 09:33
  • 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

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 22 May 12:02
6e79587

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

3.7.3

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 22 May 12:03
7e719cf

Dependency upgrades

  • Bump org.springframework.boot:spring-boot from 3.5.9 to 3.5.14
  • Bump org.springframework:spring-core from 6.2.15 to 6.2.18
  • Bump org.springframework.security from 6.5.7 to 6.5.10
  • Bump org.eclipse.jetty:jetty-bom from 12.1.7 to 12.1.9
  • Bump io.projectreactor:reactor-core from 3.8.3 to 3.8.5
  • Bump org.apache.logging.log4j from 2.25.3 to 2.25.4
  • Bump org.slf4j:slf4j-api from 2.0.17 to 2.0.18
  • Bump org.apache.httpcomponents.client5:httpclient5 from 5.6 to 5.6.1
  • Bump com.github.ben-manes.caffeine:caffeine from 3.2.0 to 3.2.4
  • Bump commons-io:commons-io from 2.21.0 to 2.22.0
  • Bump org.mockito:mockito-core from 5.22.0 to 5.23.0
  • Bump com.github.spotbugs:spotbugs-maven-plugin from 4.9.8.1 to 4.9.8.3
  • Bump com.sap.cloud.environment.servicebinding:java-bom from 0.21.0 to 0.31.0

4.0.5

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 04 May 13:11
2f9e42e
  • 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

3.7.2

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 04 May 13:10
d1f6f21
  • 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

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 23 Apr 09:22
acb1d15

improve domain validation handling

3.7.1

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 23 Apr 09:21
c78bfb5

improve domain validation handling

3.7.0

Choose a tag to compare

@NiklasHerrmann21 NiklasHerrmann21 released this 16 Apr 12:11
cf52a80
  • Split token-client module into three modules for improved dependency management:
    • token-client-core: Plain Java implementation without Spring dependencies
    • token-client-spring: Spring-specific implementations (SpringOAuth2TokenKeyService, SpringOidcConfigurationService, XsuaaOAuth2TokenService)
    • token-client: Wrapper module including both for backward compatibility
  • Applications without Spring can now use token-client-core to avoid unnecessary Spring dependencies
  • Existing applications using token-client continue to work without changes
  • java-security module now depends on token-client-core instead of token-client (removing unnecessary Spring transitive dependencies)