Make it possible to use Spring Security with functional bean registration

[sdeleuze]

We would like to start adding Spring Security support in Spring Fu (via an external contributor) but we are currently blocked because unlike Spring Boot configurations, it is not possible to inject programmatically required beans in Spring Security configuration classes.

Our goal is to provide a functional bean registration equivalent of @EnableWebFluxSecurity which imports following configurations:

• ServerHttpSecurityConfiguration
• WebFluxSecurityConfiguration
• ReactiveOAuth2ClientImportSelector$OAuth2ClientWebFluxSecurityConfiguration

We would like to use these configuration classes like we use Spring Boot configuration classes in https://github.com/spring-projects/spring-fu/tree/master/autoconfigure-adapter, but autowired private field make that impossible.

To solve this, autowired fields should be injectable via protected/package private setters or constructor parameters. That has also the benefit to make these classes easily testable.

Any chance you could make these changes to allow us to move forward on functional configuration for Spring Security?

[rwinch]

@sdeleuze Thanks for the report! We definitely want to enable this to progress. Are there reasons that the DSL only makes sense for functional beans and not allowing it to be used in standard Spring Security setups? I'm asking because we have had this sort of request before.

[sdeleuze]

I have also that goal in mind, the Kotlin DSL that will arise on Spring Fu incubating side could be usable in regular Javaconfig mode as well, like we do on WebFlux router and bean registration side. My plan is to provide a PR for that at some point, when that will be mature enough.

[jgrandja]

@sdeleuze I'm not sure it makes sense to expose setter/constructor params in the @Configuration classes. NOTE: ServerHttpSecurityConfiguration, WebFluxSecurityConfiguration and ReactiveOAuth2ClientImportSelector are package-private as well so these would need to be exposed as well, which again we're not really keen on.

We definitely want to help move this forward for you, I'm just not seeing how reusing @Configuration makes sense for functional @Bean registration. Maybe I'm missing something and you can help me better understand?

Would you consider using ServerHttpSecurity directly to configure it functionally and than register it as a @Bean via the ApplicationContextInitializer adaptor module? Let me know if this strategy would work for you.

[sdeleuze]

Like for Spring Boot features I use in Spring Fu, the idea would be to use package private only setters, use the same Spring Security package on Spring Fu side and later reintegrating the DSL in Spring Security itself. That's why I am only asking for package private access, nothing more.

I will use ServerHttpSecurity but I think I need to be able to register the previously mentioned configurations functonaly in order to be able to get the ServerHttpSecurity instance.

[jgrandja]

the idea would be to use package private only setters, use the same Spring Security package

I get it now...somehow I misunderstood when I read your comments previously. Let me put something together for you and we can review from there.

[jgrandja]

@sdeleuze See #6761 and please confirm if this is what you're looking for.

@rwinch Please review and let me know if you're good with this approach. I'll add tests to complete the PR after we're all on the same page.

[sdeleuze]

@jgrandja Yes this is exactly that :-) I have just added a question in the PR, see 85abc75#r273683479.