create-session stateless usage

Question

I was hoping that changing into create-session="stateless" would be the end of it to achieve stateless spring security in my webapp, but it is not so.

With that change, the spring security seems to be not working, since (my assumption) spring security doesnt store anything in the session, and cannot do authentication to secured web requests.

How do i make use of this stateless feature ?

I cannot seem to find any relevant examples yet on how to achieve stateless spring security for a stateless webapp.

Thank you !

Answer 1

Donal's answer is basically correct, and for a browser you probably don't want to be using a stateless app.

For reference, create-session="stateless" is a better option if you really do have a stateless app such as a RESTful client. This option was introduced in Spring Security 3.1. It will avoid adding parts of Spring Security's infrastructure which make use of the session (e.g. HttpSessionSecurityContextRepository, SessionManagementFilter, RequestCacheFilter), so you get a leaner setup.

With create-session="never", Spring Security will never create a session itself, but will make use of one if your app does. In practice, many users aren't even aware that they are creating sessions, so if you really don't want a session, ever, then stateless is the best option.

Answer 2

I have a Spring-based webapp which has fully stateless security, and the only way to make it work like that is to disable session creation completely (with create-session="never"). That forces re-authentication with each request, so you'll be wanting to also configure the webapp to use HTTP Basic Auth or Digest Auth (over HTTPS, of course) as those don't require a particularly complex negotiation (by contrast, form-based login and OAuth both require a session because they have a much more complicated process for establishing the authentication context). That means you'll want to put an element like <security:http-basic /> inside your <security:http> element.

(The advantage of doing it this way is that it enables extremely simple client libraries as they don't have to do cookie/session management. The cost is some processing overhead — the establishment of what set of roles the user is participating as will have to be recomputed on each request — and some limitations on which authentication mechanisms you can use.)