Bump the minor-patch group across 1 directory with 2 updates

[dependabot]

Bumps the minor-patch group with 2 updates in the /ams-cap-bookshop directory: com.sap.cloud.security.ams:ams-bom and com.sap.cloud.security:java-bom.

Updates com.sap.cloud.security.ams:ams-bom from 4.2.1 to 4.3.0

Commits

• See full diff in compare view

Updates com.sap.cloud.security:java-bom from 4.0.7 to 4.0.8

Release notes

Sourced from com.sap.cloud.security:java-bom'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.

Changelog

Sourced from com.sap.cloud.security:java-bom'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.

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
• See full diff in compare view

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.