Consider adding common scenario/pattern based security configurations

[asaikali]

Spring security has a massive number of configuration options and it can be quite overwhelming to know which combination of security configurations to use. It would be nice to provide some out of the box common configuration settings that configure spring security with "reasonable" secure defaults for a specific use case. For example something like CommonSecurityConfigurations.restApi(); should turn on all recommend spring security configuration for securing a rest api without having to configure every setting. A brain storm of possible scenario / pattern based configuration settings:

• configure security for a Rest API
• configure security for a GraphQL API
• configure security for a server side rendered web app

The key goal is to enable the developer to think in terms of higher level capabilities so that they can declare to spring security my app needs pattern x, y, and z and have spring security provide a configuration that is recommend for x,y,z. Ideally the scenarios can be composed together but I am ok if they can't be.

Related gh-13266

[jzheaux]

I wonder how opinionated such pre-configurations can/should be. .restApi already presents the possibility of HTTP Basic vs Bearer, so which do we pick? And to what degree can we change that opinion as security recommendations change?

Also, either choice requires some authentication source like a UserDetailsService or JwtDecoder which somewhat undermines what I hear as the goal.

For example, the following already supplies all of Spring Security's reasonable defaults for a JWT-based REST API:

@Bean 
SecurityFilterChain restSecurity(HttpSecurity http) {
    return http.oauth2ResourceServer((oauth2) -> oauth2
        .jwt((jwt) -> jwt.jwkSetUri("https://jwks.example.org"))
        .build();
}

which is already minimal, as far as I can tell.

Perhaps we could provide a subset of the DSL for given scenarios, like so:

@Bean 
RestApiConfigurer restSecurity() {
    return (restApi) -> restApi
        .httpBasic(...)
        .oauth2ResourceServer(...);
}

In this way, the number of options is reduced (for example, .sessionManagement, .formLogin, .oauth2Login, and .saml2Login all might be removed). I'm not really a fan of the maintenance cost, though.

Alternatively, I think #13057 would go a long way to removing the kind of boilerplate this ticket seems to allude to. With #13057, parts of the DSL unrelated to my app's customizations wouldn't need to be known and re-specified by me, the developer.