Spring-boot: Spring Security Autoconfiguration isn't stateless anymore

[michael-simons]

This is a follow up of https://twitter.com/rotnroll666/status/904998421618196481

The attached two projects are identical apart from being BUILD-SNAPSHOT vs M3.
demo-sec-build-snapshot.zip
demo-sec-m3.zip

There's a simple REST controller in both projects:

@RestController
@RequestMapping("/api")
public class ApiController {

    @GetMapping("/greeting")
    public String getGreeting(
        final Principal principal)
    {
        return String.format(
            "Hello, %s.",
            Optional.ofNullable(principal)
                .map(Principal::getName)
                .orElse("Anonymous"));
    }
}

Spring Security generates a password in both cases and logs it to console as expected.

Basic auth does work with both projects.

But the build snapshot generates a session and a corresponding cookie / session id and offers a form login (which works)

curl -v http://localhost:8080/api/greeting
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> GET /api/greeting HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.51.0
> Accept: */*
> 
< HTTP/1.1 302 
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Set-Cookie: JSESSIONID=81C71E0637FAA72F423FFBC4139BFA46; Path=/; HttpOnly
< Location: http://localhost:8080/login
< Content-Length: 0
< Date: Tue, 05 Sep 2017 09:18:52 GMT

Basic-Auth still works, though.

The session creation policy that was set to SessionCreationPolicy.STATELESS before disappeared through @mbhave's change https://github.com/spring-projects/spring-boot/commit/e08ddbf838a54e589c07e2be36153a3f330f9550

If it stays that way it should be documented in the reference.

[michael-simons]

I just found that

Security’s content-negotiation strategy to determine whether to use httpBasic or formLogin.

on the wiki page https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Security-2.0

which actually works quite nice. So it's basically a documentation issue.

[pivotal-cla-link]

@michael-simons This is expected behavior. The new Boot Security auto configuration leans on Spring Security's defaults more heavily. The default for Spring Security is to perform content negotiation to determine if form login or basic authentication should be performed.

Basic authentication with session is a pretty common pattern. This is important because if you are storing your passwords with a modern password hash that is configured correctly (i.e. BCrypt or PBKDF2) your password takes half a second to validate. If you are not creating a session and validating the password on every request, then that means there is no way to make your request faster than half a second (which is pretty slow).

Of course these are simply defaults. You are free to override the values if you need. In fact, we fully expect that it is very rare for applications to use the default security settings in any production application. These defaults are simply meant to ensure the application is secured and provide a meaningful and helpful stepping stone toward implementing your own security.

Can you explain why/how the change is causing you problems? Perhaps that can help us to find a solution for you.

[michael-simons]

The password validation argument is an interesting one in many regards, but more an architectural discussion.

The change is not yet causing any troubles for me, I know early enough to adapt. Caught me as a suprise, as I just skimmed the changelog and didn't read the dedicated wiki page.

I am not sure wether each Boot user will know the (new) defaults of Security so I'd expect them in some form in the docs.

Anyway, thanks for taking my feedback into concern.

[snicoll]

The release notes for 2.0 aren't complete and we have a blog post on that very topic that we need to finalize. We usually update the release notes at the end of the Dec cycle anyway.

Do I understand that this issue is closed?

[mbhave]

@michael-simons thanks for pointing out the documentation gap. We are still ironing out a few things and will update the docs shortly. I've kept the original issue open for doc updates.

[mbhave]

I think @snicoll and I replied simultaneously! I'll go ahead and close the issue in favor of #7958