Use permitAll for CloudFoundry endpoints

[jzheaux]

Spring Security 5.8/6 supports delaying the lookup of the SecurityContext until an authorization rule requires it.

As such, it's preferred to use authorizeHttpRequests#permitAll over web.ignoring(). In the past web.ignoring() was added as a quick workaround to address the performance impact of looking up the SecurityContext on every request. Now, Spring Security defers that work until authorization-time and in the case of permitAll, no authorization is performed.

Consider the following application:

@Bean 
SecurityFilterChain app(HttpSecurity http) {
    http
        .authorizeHttpRequests((authorize) -> authorize
                .anyRequest().authenticated()
        )
        // ...

    return http.build();
}

@Bean 
WebSecurityCustomizer ignore() {
    return (web) -> web.ignoring().antMatchers("/cloudfoundry/**");
}

The behavior of the above application asks Spring Security to protect all endpoints other than /cloudfoundry.

As of Spring Security 5.7, this produces a warning that web.ignoring() is not recommended since this prevents Spring Security from using its WAF and writing secure HTTP response headers for those ignored endpoints.

Alternatively, the application can do the following:

@Bean 
SecurityFilterChain app(HttpSecurity http) {
    http
        .authorizeHttpRequests((authorize) -> authorize
                .mvcMatchers("/cloudfoundry/**").permitAll()
                .anyRequest().authenticated()
        )
        // ...

    return http.build();
}

Or, if it should be considered entirely separate:

@Bean 
SecurityFilterChain app(HttpSecurity http) {
    http
        .authorizeHttpRequests((authorize) -> authorize.anyRequest().authenticated())
        // ...

    return http.build();
}

@Bean 
@Order(-1)
SecurityFilterChain cloudfoundry(HttpSecurity http) {
    http
        .securityMatchers((matches) -> matches.requestMatchers("/cloudfoundry/**"))
        .authorizeHttpRequests((authorize) -> authorize.anyRequest().permitAll());

    return http.build();
}

This has the additional benefit of removing Spring Security's warning message.

[somayaj]

Hi @mbhave @maystefan @jzheaux is this still a bug to be worked on?

[somayaj]

Hello, is there an agreement here on the approach to follow?

[scottfrederick]

@somayaj We haven't had the time to look closer at this issue with other priorities we're working on.