SAP BTP Security Services Integration Library

The java-security-test library provides utilities for writing JUnit tests for applications secured with java-security, spring-security, or spring-security-3 without requiring a real SAP BTP Identity or XSUAA service instance.

It achieves this by:

1. Starting a WireMock server on localhost pre-configured with stubbed responses for JWKS and OIDC endpoints.
2. Providing a JwtGenerator to create custom JSON Web Tokens (JWTs) signed with keys that match the stubbed JWKS.
3. Offering an optional Jetty application server for Java EE applications, pre-configured with a security filter that only accepts valid tokens.

This allows for offline, local testing of both Spring Boot and Java EE security layers.

The SAP BTP Security Services Integration Libraries provide tools to simplify integrating SAP Business Technology Platform (SAP BTP) security services (XSUAA and Identity Services) into Java applications.

Key capabilities include:

• OAuth 2.0 Token Validation: Streamlined validation for tokens issued by XSUAA and Identity Services.
• Token-Client Library: Easily fetch tokens for HTTP requests without complex manual setup.
• Testing Utilities: Mocking of XSUAA and Identity service behaviors for unit and integration testing.

Important Constraint: These libraries are designed and tested exclusively for SAP BTP (Cloud Foundry and Kubernetes/Kyma). They rely on service bindings and environment discovery (Environments.getCurrent()) provided by the SAP BTP runtime. Usage in other environments (on-premise, other clouds) is not supported.

This Spring Boot sample application demonstrates how to use the spring-security module to validate JWT tokens from two different sources:

1. XSUAA Service: Provides OAuth access tokens.
2. Identity (IAS) Service: Provides OIDC tokens.

Even though the token claims differ between these services, the validated token is consistently accessible as a Token via the Spring org.springframework.security.core.context.SecurityContextHolder.

The sample also demonstrates the CorrelationIdFilter, which:

• Appends a correlation_id to the MDC context.
• Uses that ID to augment outgoing requests with an X-CorrelationID header.

For Java EE applications, you can start an embedded Jetty server via .useApplicationServer() in your Rule or Extension.

Key features:

• Security: It is pre-configured with a TokenAuthenticator that blocks requests (HTTP 401) if they do not contain a valid JWT from the JwtGenerator.
• Servlet Mounting: Servlets mapped in web.xml are mounted automatically. For annotation-based servlets, use .addApplicationServlet(Class, path) to mount them manually.
• Filters: You can add custom filters using .addApplicationServletFilter(...) to test specific routes based on roles or scopes.

Unlike the deprecated (XS)UserInfo methods which automatically handled token information, the token-client library decouples the flow from the token.

When performing a user token flow (an exchange flow), you must explicitly pass the existing user token to the token method.

• If you are already using the new API, obtain the token via getTokenValue().
• If you are still using the deprecated (XS)UserInfo, obtain the token via getAppToken().

In a Spring WebFlux (reactive) application, the standard autoconfiguration for JwtDecoder only works for Servlet-based applications. To use the resourceserver-security-spring-boot-3-starter in a reactive environment, you must implement a manual SecurityConfiguration to configure the reactive JWT decoder and authentication converter.

Once validated, the token is accessible as a Token via the ReactiveSecurityContext.

The spring-security-3 module uses Apache HttpClient 4.5 for HTTP communication.

This differs from the main spring-security module (intended for Spring Boot 4.x), which uses the Java 11 HttpClient.

The token-client library uses Java 11 HttpClient by default. If you require advanced features like proxy configurations, custom connection pooling, mTLS, or specific retry logic, you can provide a custom implementation by implementing the HttpRequestExecutor interface and wrapping it in a CustomHttpClientAdapter.

@FunctionalInterface
public interface HttpRequestExecutor {
    HttpResponse execute(URI uri, String method, Map<String, String> headers, byte[] body)
        throws HttpClientException;
}