X509 Reactive Support

[rwinch]

Summary

Now that Spring Framework provides X509 information, we should provide authentication mechanism using it. See https://jira.spring.io/browse/SPR-15964

[alek-sys]

Hey @rwinch, are there any updates on that issue? Is seems it was scheduler for 5.1 but I cannot find it there. WebFlux seems to be supporting that now https://jira.spring.io/browse/SPR-15964

[rwinch]

@alek-sys Thanks for the nudge. We just haven't had time to add the support. Would you be interested in contributing this support?

[alek-sys]

I'm happy to! If there is any guidance you'd like to provide it is much appreciated. Should it be just an implementation of ServerAuthenticationConverter or do you see that as some sort of preauth mechanism similar to original X509AuthenticationFilter?

[rwinch]

Thanks! I think that it could be done by creating a ServerAuthenticationConverter (as you suggested) plus a ReactiveAuthenticationManager and injecting those into the existing AuthenticationWebFilter.

[samhaque]

@rwinch I followed the documentation for x509 auth for reactive applications(my app is a spring cloud gateway application) as mentioned here:
https://docs.spring.io/spring-security/site/docs/current/reference/html5/#reactive-x509

However I noticed some weird behaviour, where even after creating a chain like this:

 http
        .x509(x509 -> x509
            .principalExtractor(principalExtractor)
            .authenticationManager(authenticationManager)
        )
        .authorizeExchange(exchanges -> exchanges
            .anyExchange().authenticated()
        );

and setting the authenticationManager to accept certs with the common name I want:

    SubjectDnX509PrincipalExtractor principalExtractor =
            new SubjectDnX509PrincipalExtractor();

    ReactiveAuthenticationManager authenticationManager = authentication -> {
        authentication.setAuthenticated("MY_TRUSTED_CN".equals(authentication.getName()));
        return Mono.just(authentication);
    };

it still defaults to http basic auth. Also since there is no debug logging in spring security for reactive apps( #5758), it is especially hard to debug inside PCF as the java buildpack takes the client cert from the go routers as a header and injects it into the keystore, and Spring Security just logs the GET/POST event but does not log any logger.debug lines even though I set the log level for spring security in my application.yml to DEBUG.

Let me know if you want this as a separate issue, I am pretty sure I am doing something wrong here as the implementation does make sense.

[rwinch]

@samhaque Please create a separate issue and provide a complete sample/directions to reproduce.

[alek-sys]

Hey @samhaque, keep in mind mTLS via XFCC header on PCF is tricky. There are two important things to consider:

• If you have HAproxy in your deployment, XFCC header gets stripped out from the request so you won't be able to use mTLS security
• For reactive stack, client certificate is not correctly mapped to request properties, there is an open PR to JBP Client Certificate Mapper

[samhaque]

Hey @samhaque, keep in mind mTLS via XFCC header on PCF is tricky. There are two important things to consider:

• If you have HAproxy in your deployment, XFCC header gets stripped out from the request so you won't be able to use mTLS security

• For reactive stack, client certificate is not correctly mapped to request properties, there is an open PR to JBP Client Certificate Mapper

We have a isolated segment for mTLS, so it's not a HAproxy issue.

Is it possible to review that PR so the certificate mapping issue can be fixed in the next release?

[alek-sys]

Is it possible to review that PR so the certificate mapping issue can be fixed in the next release?

I'm not sure. Feel free to comment on the PR to show your interest, but even when it is merged it'll take some time to update and release JBP. For now you can just bring this filter to your codebase, unitl JBP is updated.

[rwinch]

Closing this as a duplicate of the merged PR gh-6336