2

We have some endpoints, that are secured and before to access them we're verifying that the jws is correctly. In order to do that, we've defined a SecurityContext that actually persist the Auth pojo and to manipulate it downstream into the controller. The SecurityWebFilterChain config looks like that:

@Bean
public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) {
    return http.csrf().disable()
            .formLogin().disable()
            .logout().disable()
            .httpBasic().disable()
            .securityContextRepository(securityContext)
            .authorizeExchange()
            .anyExchange().authenticated()
            .and()
            .build();
}

The calls were internally made, and we just verified the jws token.

Right now some external clients need to integrate with us, and we need to verify a jwe token. The thing is, that somehow we need to tell spring-security to validate for the existent endpoints the jws and for the new one the jwe.

I tried by specifying multiple security matchers but it failed :( . Do you have any other suggestions ?

brebDev
  • 774
  • 10
  • 27

1 Answers1

16

You can expose more than one bean. I recommend specifying an order:

@Bean
@Order(1)
public SecurityWebFilterChain first(ServerHttpSecurity http) {
    http
        .securityMatcher(...)
        ...

    return http.build();
}

@Bean
@Order(2)
public SecurityWebFilterChain second(ServerHttpSecurity http) {
   http
       .securityMatcher(...)
       ...

   return http.build();
}

As a side note, Spring Security does ship with support for verifying JWS tokens reactively, and you might be able to remove some boilerplate by using it.

jzheaux
  • 7,042
  • 3
  • 22
  • 36
  • Thanks jzheaux and sorry for the late response. Yep as you've said I've configured two SecurityWebFilterChains with two different securityMatcher, two securityContext and I've ordered them in order for the most specific one to be the first one. I didn't know that spring security has support for verifying the jws(I used this one: org.jose4j.jwt.consumer), but I'll consider it in the future. Cheers! – brebDev Feb 25 '19 at 13:06
  • @jzheaux sorry for the confusion , i meant order works fine with WebSecurityConfigurerAdapter but not with SecurityWebFilterChain. Here is my question in the forum . https://stackoverflow.com/questions/59471908/multiple-authentication-strategy-for-spring-reactive-webflux-microservices – Tatha Dec 24 '19 at 17:37
  • 3
    I can confirm that providing two different SecurityWebFilterChain beans works. Specifying securityMatcher seems to be required. – Rüdiger Schulz Apr 13 '20 at 22:48
  • 1
    I also confirm that using `securityMatcher` is the key for success. It's not enough to use any other matchers. – judomu Aug 14 '20 at 21:12
  • After reading the code of `ServerHttpSecurity`, I can confirm that `securityMatcher` is the key point, because that is the only method that could set the `matcher` field in `ServerHttpSecurity`. Other so-called matcher methods only set filters. How the proxy works is that it follows a list of `SecurityWebFilterChain` and tries to call the matcher of each one, as soon as it gets a match, it uses that chain's filters and then ignores all other `SecurityWebFilterChain`. If you do not use `securityMatcher`, the default matcher matches everything, causing proxy to only use the first one. – bfrguci Oct 22 '21 at 08:22