Before we go to spring security session management let first understand what is session and why session is required.
Whenever we connect to any web server through URL, we use browser as client which uses a HTTP protocol for communication between browser and server. HTTP is a “stateless” protocol which means each time client receives a web page, the client opens a separate connection to web server and server automatically does not keep any record of previous client request that means for web server every request is a new request to process and they can’t identify if it’s coming from client that has been sending request previously. But sometime in web applications, we should know who client is and process the request accordingly.
Session is a conversional state between client and server and it consists of multiple request and response between client and server. Since HTTP protocol and web server both are “stateless” the only way to maintain a session is when some unique information about session like session id is passed between server and client in every request and response. In other words session is unique Id created by container to identify the user from whom the request in coming in
.
Now we jump to how is session management takes place in spring security.
When is session created?
We can control exactly when our sessions get created and how spring security interact with it.
1. always – a session will always be created if one already does not exist
2. ifRequired – a session is created if required (Default).
3. never – a framework will never create a session itself. But it will use one if it already exists.
4. Stateless – no session is created or used by spring security.
<http create-session=”ifRequired”>….</http>
It is very important to understand that this configuration only controls what spring security does – not the entire application. Spring security may not create the session in we instruct it not to, but our application may!
By default spring security will create session when it needs one. This is ”ifRequired”
For a more “stateless” application, the “never” option will ensure that spring security itself will not create any session; however if application creates one, the spring security makes use of it.
Finally, the strictest session creation option – “stateless” – is guarantee that the application will not create any session at all.
Concurrent Session Control
When a user that is already authenticated tries to authenticate again, the application can deal with that event in one of a few ways. It can either invalidate the active session of the user and authenticate the user again with a new session, or allow both sessions to exist concurrently.
First step in enabling the concurrent session-control support is to add the following listener in the web.xml:
<listener>
<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>
This is essential to make sure that the Spring Security session registry is notified when the session is destroyed.
To enable the scenario which allows multiple concurrent sessions for the same user the element should be used in the XML configuration:
<http …>
<session-management>
<concurrency-control max-sessions=”3″ />
</session-management>
</http>
Session Timeout
After the session has timed out, if the user sends a request with an expired session id, they will be redirected to an URL configurable via the namespace:
<session-management>
<concurrency-control expired-url=”/sessionExpired.html” … />
</session-management>
Similarly, if the user sends a request with a session id which is not expired, but entirely invalid, they will also be redirected to a configurable URL:
<session-management invalid-session-url=”/invalidSession.html”>
…
</session-management>
Best Open Source Business Intelligence Software Helical Insight is Here
