We Keep Coding

Session management using spring security

I have created a basic spring security authentication using UserDetailsService and now I am able to validate user. However, I don't understand how to achieve below things:
Once a user is logged in, when next request comes how and where do I check if the request is coming from the same logged in user or other logged in user?
I know the concept of Spring interceptors where I can intercept all incoming request. But is there something in spring security that does this?
How can I start a session after logging in and store values in session for that user?
I browsed through existing answers but most of examples are for logging in.
I would appreciate if someone can give me examples.
EDIT:
I think I should use session scoped beans in order to maintain user's session contents rather than manipulating httpsession directly.

I think you really need to spend some time reading the Spring security documentation and over all JSP, servlet and MVC architecture. You have several misunderstandings,
After authentication, you don't need to start a session it was already there when the request came. Remember request.getSession()we get the session from the request and I am really NOT aware of any other way i.e. instantiating session object and assigning it to request/response. After successful authentication spring automatically sets a SPRING_SECURITY_CONTEXT attribute in session and this variable is later used to determine whether user is already authenticated or not (Spring does that for you, you don't need to use this attribute).
In spring security we set an authentication entry point which has information about login page url and FORM_LOGIN_FILTER which has information about login processing url, login success url and login failure url among few other things.Every request whose session doesn't have SPRING_SECURITY_CONTEXT and auth attribute gets redirected to login page url.
I could give the code directly but it would be great if you read at least few pages of Spring documentation here. Once you understand the concepts and are still not able to solve the problem. Edit your question with detailed problem and we will try to fix it.

At first you need to create an Authentication object using current HttpRequest as below:
public class SessionService{
public Authentication getSession(HttpServletRequest request) {
HttpSession session=request.getSession();
SecurityContext ctx= (SecurityContext) session.getAttribute("SPRING_SECURITY_CONTEXT");
Authentication auth=ctx.getAuthentication();
return auth;
}
}
Then, you can retrieve the session details from this Authentication object by passing the current HttpRequest as follows:
Authentication auth = sessionService.getSession(request);
The above auth object contains the details that you need.

How to prevent session attributes from persisting on the server?

I'm new to java web development. I have created a servlet/jsp web application that is deployed on Tomcat 7. After authentication, the user go through few page that has its own forms. The inputs are stored as session attributes and are displayed on a confirmation before log out.
For the log out, I used session.invalidate() and sendRedirect("Logout.jsp").
If I run the application again, it will return my new input, but it will also copy all the old session input.
I have disabled the session persistence and put the context cachingAllowed="false".
It seems that all the session attributes are stored in the server memory. Is this problem causes by the server configuration?

Make sure you use request.getSession(boolean b) method and not the request.getSession()
All page that should be accessible to logged in user should make a call to request.getSession(false)
If call to this method does not return any session, user should be redirected to login.

make sure your information store in session like this:
HttpSession session = request.getSession();
session.setAttribute("info", info);
when you want to remove it,you should do it like this:
HttpSession session = request.getSession();
session.removeAttribute("info");

AuthenticationProvider authenticate called twice in IE and fails to login

I have a custom AuthenticationProvider with the authenticate method.
#Override
public Authentication authenticate(Authentication authentication) throws AuthenticationException {
> Check username, password, throw exceptions where needed
return new CustomAuthenticationToken(username, grantedAuthorities);
}
And the token:
public class CustomAuthenticationToken extends UsernamePasswordAuthenticationToken
{
public CustomAuthenticationToken(ICurrentUserContext currentUser, List<GrantedAuthority> authorities) {
super(currentUser.getUsername(), currentUser.getPassword(), authorities);
}
}
When I login with Chrome, Firefox, there is no problem whatsoever.
In IE 8/9 I have a very weird problem. Sometimes it will only call the method authenticate one time, it will login and everything works as expected. But from time to time, it will call authenticate twice, and fails to log in.
Does anybody have any clue?
I've tested it on Tomcat btw.

I've found the problem, with careful tracing the debug log of the Spring Security.. Hopefully this will help someone in the future.
Apparantly, spring security default migrates sessions after login. But in IE it does not migrate the authentication cookie to the new session, resulting in presenting of the login page.
The fix is easy, and can be done in the Spring Security xml:
<http use-expressions="true">
<!--
This settings is for IE. Default this setting is on migrateSession.
When IE tries to migrate the session, the auth cookie does not migrate,
resulting in a nice login screen again, after you've logged in.
This setting ensures that the session will not be invalidated, and thus IE will still work as expected.
-->
<session-management session-fixation-protection="none" />
</http>

Look at this please Internet Explorer buggy when accessing a custom weblogic provider.
Maybe you habe to disable cookies no your Tomcat

Migrating the session is entirely a server-side process and should be invisible to the browser. All it should see is a new Set-Cookie header for the JSESSIONID, which it should respect.
My best guess is that you are seeing this tomcat bug, which will cause different effects depending on how a browser interprets the duplicate headers. It was originally reported because of this issue with a Blackberry browser which is closely related to what you're seeing here.
But you don't say which versions of either Spring Security or Tomcat you are using (always a good idea :-)), so it's hard to say for sure.

Table of contents
Quick Reference
Spring Security Core plugin
<< 17IP Address Restrictions19Logout Handlers >>
18 Session Fixation Prevention - Reference Documentation
Authors: Burt Beckwith, Beverley Talbott
Version: 2.0-RC3
18 Session Fixation Prevention
To guard against session-fixation attacks set the useSessionFixationPrevention attribute to true:
grails.plugin.springsecurity.useSessionFixationPrevention = true
Upon successful authentication a new HTTP session is created and the previous session's attributes are copied into it. If you start your session by clicking a link that was generated by someone trying to hack your account, which contained an active session id, you are no longer sharing the previous session after login. You have your own session.
Session fixation is less of a problem now that Grails by default does not include jsessionid in URLs (see this JIRA issue), but it's still a good idea to use this feature.
Note that there is an issue when using the cookie-session plugin; see this issue for more details.
The table shows configuration options for session fixation.
Property Default Value Meaning
useSessionFixationPrevention true Whether to use session fixation prevention.
sessionFixationPrevention.migrate true Whether to copy the session attributes of the existing session to the new session after login.
sessionFixationPrevention.alwaysCreateSession false Whether to always create a session even if one did not exist at the start of the request.
http://grails-plugins.github.io/grails-spring-security-core/guide/sessionFixation.html

Should we reset the session variables to null on web application logout?

Httpsession is per browser.Ideally should we reset the session variables on logout otherwise it will always be available for that Browser even user login again.Is that correct?

You can just invalidate the session by calling HttpSession.invalidate() which will clear all the attributes as well as destroy the session itself.

You don't need to reset all session variables. You just need to call session.invalidate() and servlet framework will take care of the rest.

Java Request.isRequestedSessionValid() still true after session expires

I am using Spring Security 3.0 and created a custom filter to check for expired sessions.
My problem is that request.isRequestedSessionValid() returns true in my filter even after I let the session expire or log out. If I try to access any secured page, I do get redirected to my login page so I know that the session management works.
My understanding was that when a web session times out, the session is automatically invalidated and I also set invalidate-session in my logout element of Spring Security. How can the session still be valid? Am I checking the wrong value?

request.isRequestedSessionValid() can itself cause a session to be created, even after logout has been called. Use request.getSession(false) != null to check instead, which will ensure that a session is not created.