I am new with spring ,I have a doubt about spring session management and spring security session ,whether both concept are same or different ? If different what are that ? Any suggestion ?
May you be a little bit more specific in your question?
In Spring:
session can refer to one of the scopes that a bean belongs to. For example, if you define an instance (bean) of a class a org.something.Counter with scope session, whenever you will access that bean during a web session you will have the same instance of the object. Web session does not require Spring Security in order to exists. You can start from here to understand a little bit more about the session scope in Spring.
session may refer to HttpSession as speciffied by the Servlet API. This is not really related to Spring, even if you can use the standard HttpSession from within Spring, is more in general related to the Servlet API.
In Spring Security:
If you are talking of Spring Security, instead of session I would talk of SecurityContext. The SecurityContext is actually stored as an HttpSession and restored to the SecurityContextHolder at every request. Here is were all security-related infos are stored for the current session. See here for more details. In general a SecurityContext (at least at a very basic level) exists from the moment you login to the moment you logout. Because it is stored as an HttpSession it expires when the HttpSession expires (again, see the Servlet API specifications for more details)
Luca
Related
How does spring security maintain authentication info between requests?
Does it use any thing similar to jSessionId or uses an entirely different mechanism.
Further, I see that the AbstractSecurityInterceptor (I mean, any of it's implementations) is responsible for intercepting the incoming request and verify if a request is already authorized using Authentication.isAuthenticated() and then depending on the condition either validate the request or send the Authentication request to an AuthenticationManager Implementation. So, in other words, how does AbstractSecurityInterceptor differentiate between first request and subsequent request.
Spring Security uses a SecurityContextRepository to store and retrieve the SecurityContext for the current security session.
The default implementation is the HttpSessionSecurityContextRepository which utilizes the javax.servlet.http.HttpSession to store/retrieve the SecurityContext.
The underlying servlet container will obtain the correct HttpSession for the incoming request, generally due to a session identifier being passed in a cookie or request parameter. For Spring Security it doesn't matter as that is thus loaded of to the underlying servlet container.
In my application, when a user updates their username, I want to clear that authentication from the security context because the old username was used in basic auth calls.
In my controller doing the update, this is easy enough with
SecurityContextHolder.getContext().setAuthentication(null);
But I'm looking for a way to access the current security context without using static methods for ease of unit testing (not to mention the static call doesn't seem very "springy").
The answer here looks pretty close to what I'm looking for, but I'm hoping there's a way to do this without writing a wrapping class. I also tried to inject SecurityContextHolderStrategy into my controller constructor (as was implied I might be able to do in that answer and the related jira) and there was no bean defined of that type.
So: Is there a way to access the current SecurityContext in a Spring Controller without using SecurityContextHolder static methods?
My version of spring security is 3.2.5.RELEASE.
When i am trying to use #PreAuthorize("#accessControl.hasActivity('abc')") on spring controller method i am getting Authentication object was not found in security context.
After debugging found that DispactcherServlet is throwing this exception.
i have set SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_THREADLOCAL);
when i first create Authentication object and set in security context
Also tried with SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL); but no luck still it does not work.
I am not able to understand why spring is servlet is throwing this exception
First, doing authentication in a Spring MVC interceptor is odd. Consider using a filter before DispatcherServlet. There is a lot of documented examples.
Secondly, SecurityContextHolder.setStrategyName re-initializes the strategy and possibly makes all previously authentications inaccessible so you must only call it once (if any time), before any authentication is made.
Thirdly, if you want to set the current authentication to be used by #PreAuthorize and are sure what you are doing, use SecurityContextHolder.getContext().setAuthentication(anAuthentication);. In most cases, there is a suitable filter in the API that already does this for you.
I'm using springsecurity to protect some EJB methods deployed on jBoss 5.1.0.
I'm looking for a nice way to transfer the java.security.Principal retrieved from the EJBContext, by calling getPrincipal(), to the Spring SecurityContext.
I wouldn't like to give up the springsecurity schema, just need to set the Principal before the execution of the MethodSecurityInterceptor.
Any idea?
I'm doing some proof-of-concept work with Spring MVC and security. So far I've managed to write a simple web-app which has a secure webpage which requires a user to login and have the correct role before accessing the database and listing some data. I'm using Spring 2.0.8 by the way.
What I require is that, after the user has logged on, is to access the user principal object for the current session to pass into my DAO layer. I'd like to do this through the standard bean wiring, so it will have to be something determined at runtime.
Any pointers to get started ?
Cheers
Neil
SecurityContextHolder#getContext() will return a SecurityContext associated with the current user request.
From there, you can call getAuthentication().getPrincipal() to get the data associated with the logged-in user.
There is no need to inject any bean, the static method in SecurityContextHolder will take care of accessing the correct thread-local data.