Prior to this commit, CloudFoundryReactiveActuatorAutoConfiguration
registered a BeanPostProcessor replaced the WebFilterChainProxy bean
with one that handled CF security and delegated to the existing
chain.
Constructing a new WebFilterChainProxy resulted in the loss of any
firewall customization on the existing chain as Spring Security does
not provide an API to retreive the firewall from the existing chain
and apply it to the new chain.
This commit changes the approach and aligns it with its Servlet
counterpart. Instead of post-processing the filter chain proxy, a new
SecurityWebFilterChain that handles cloudfoundryapplication/**
is defined. This chain becomes part of the existing
WebFilterChainProxy, preserving any firewall customization.
Signed-off-by: aashikantkumar <aashikantkumar2@gmail.com>
See gh-51549
Previously, the CloudFoundryAuthorizationExceptions thrown for a
missing application ID or cloud controller URL were not routed
through the error handling that turned them into a SecurityResponse
with a 503 status code. As a result, they were processed by the
general exception handling which resulted in a 500 response.
This commit updates the reactive SecurityInterceptor so that the
exceptions are processed through
SecurityInterceptor::getErrorResponse. This aligns the behavior of
the Cloud Foundry security intergration in a reactive application
more closely with that of a Servlet application.
Fixes gh-51613
Move the reactive Cloud Foundry health endpoint extension into a
health-specific configuration guarded by @ConditionalOnClass. When
spring-boot-health is absent, scanning the outer configuration attempts
to resolve ReactiveHealthEndpointWebExtension and causes context refresh
to fail.
See gh-50916
Signed-off-by: Lee JiWon <dlwldnjs1009@gmail.com>
Move the Cloud Foundry health endpoint extension bean into a
health-specific configuration. This lets the actuator configuration
refresh when spring-boot-health is absent.
See gh-50857
Signed-off-by: Lee JiWon <dlwldnjs1009@gmail.com>
Reactive SecurityService#getUaaUrl() creates a new Mono on each
invocation, so the resolved UAA URL is not reused across calls. During
token validation, this can lead to duplicate /info requests when token
keys are fetched and the issuer is validated in the same flow.
Cache the resolved UAA URL after a successful lookup and add regression
tests that verify reuse after success and retry after failure.
Signed-off-by: LeeJiWon <dlwldnjs1009@gmail.com>
Previously, CloudFoundryActuatorAutoConfiguration required
RestTemplateBuilder, using it to create the RestTemplate that's used
the security interceptor. Following the modularization,
RestTemplateBuilder is only present when spring-boot-restclient is on
the classpath. In its absence, CloudFoundryActuatorAutoConfiguration
would fail.
This commit address this problem by using RestClient.Builder (and
RestClient) instead of RestTemplateBuilder (and RestTemplate). This
allows CloudFoundryActuatorAutoConfiguration to work without
spring-boot-restclient as RestClient.Builder and RestClient are
provided by spring-web that will always be there in an MVC webapp.
Fixes gh-48826
Andy Wilkinson
aashikantkumar
Manu Sridharan
Stéphane Nicoll
Lee JiWon
Brian Clozel
Phillip Webb
Moritz Halbritter