Releases: SAP/cloud-security-services-integration-library
Releases · SAP/cloud-security-services-integration-library
Release list
4.0.8
- Fix IAS proof-token validation regression under Istio / Kyma with
credential-type: X509_GENERATEDSapIdJwtSignatureValidatorwas setting thex-client_certrequest header directly fromX509Certificate#getPEM(). When the certificate originates from Istio'sx-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 withIllegalArgumentException(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 JavaHttpClientAdapteradditionally 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-bomimport 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 ofspring-boot-dependenciesso 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-zidheader (app_tid) - Token exchange now targets a tenant-agnostic endpoint built from the
uaadomainbinding property, so XSUAA resolves the tenant viaX-zid - For X.509 credentials the host's
authentication.segment is replaced withauthentication.cert.(analogous to the Node.js library), e.g.authentication.eu10.hana.ondemand.com→authentication.cert.eu10.hana.ondemand.com - Falls back to the existing subdomain-bearing endpoint when
uaadomainis missing, preserving behavior for legacy bindings
- 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
3.7.4
- 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-zidheader (app_tid) - Token exchange now targets a tenant-agnostic endpoint built from the
uaadomainbinding property, so XSUAA resolves the tenant viaX-zid - For X.509 credentials the host's
authentication.segment is replaced withauthentication.cert.(analogous to the Node.js library), e.g.authentication.eu10.hana.ondemand.com→authentication.cert.eu10.hana.ondemand.com - Falls back to the existing subdomain-bearing endpoint when
uaadomainis missing, preserving behavior for legacy bindings
- 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
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
3.7.3
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
-
Restore deprecated
HttpClientFactory.servicesfield and ServiceLoader-based factory discovery for backward compatibility- Custom
HttpClientFactoryimplementations registered viaMETA-INF/servicesare discovered again - A deprecation warning is logged when a custom factory is used, guiding users to migrate to
SecurityHttpClientFactorywithSecurityHttpClientProvider - Token services with default (no-arg) constructors continue to use the new
SecurityHttpClientProviderinternally
- Custom
-
Fix multi-tenant IAS token exchange by adding
app_tidparameter to the token exchange request inDefaultIdTokenExtension- In multi-tenant applications, IAS requires
app_tidin addition toclient_idto uniquely identify the application - The
app_tidis extracted from the incoming access token and included when present
- In multi-tenant applications, IAS requires
3.7.2
- Fix multi-tenant IAS token exchange by adding
app_tidparameter to the token exchange request inDefaultIdTokenExtension- In multi-tenant applications, IAS requires
app_tidin addition toclient_idto uniquely identify the application - The
app_tidis extracted from the incoming access token and included when present
- In multi-tenant applications, IAS requires
4.0.4
3.7.1
3.7.0
- Split
token-clientmodule into three modules for improved dependency management:token-client-core: Plain Java implementation without Spring dependenciestoken-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-coreto avoid unnecessary Spring dependencies - Existing applications using
token-clientcontinue to work without changes java-securitymodule now depends ontoken-client-coreinstead oftoken-client(removing unnecessary Spring transitive dependencies)