Spring's SecurityContextLogoutHandler notes that the clearAuthentication flag is used to:
removes the Authentication from the SecurityContext to prevent issues with concurrent requests.
What specific issue is being prevented by removing the Authentication from the SecurityContext? Why isn't simply invalidating the session (which is the other responsibility of SecurityContextLogoutHandler) sufficient?
By not clearing the SecurityContext is the concern that a SecurityContextPersistenceFilter may preserve the current authentication to a new session id? Effectively leaving the user logged in just with a new session?
What is SecurityContextLogoutHandler?
SecurityContextLogoutHandler is a handler which implements LogoutHandler.
What SecurityContextLogoutHandler does?
It performs a logout by modifying the SecurityContextHolder.
It will also invalidate the HttpSession if isInvalidateHttpSession()
is true and the session is not null.
It will also remove the Authentication from the current
SecurityContext if clearAuthentication is set to true (default).
Is SecurityContextHolder thread safe?
Yes, it's thread safe with the default strategy (MODE_THREADLOCAL) (as long as you don't try to change the strategy on the fly). However, if you want spawned threads to inherit SecurityContext of the parent thread, you should set MODE_INHERITABLETHREADLOCAL.
Also aspects don't have any "threading logic", they are executed at the same thread as the advised method.
Credit goes to #axtavt
What is authentication in Spring Security?
Authentication: The framework tries to identify the end user with the provided credentials. The authentication can be done against a third party system plugged into Spring Security.
Let's consider a standard authentication scenario that everyone is familiar with.
A user is prompted to log in with a username and password.
The system (successfully) verifies that the password is correct for
the username.
The context information for that user is obtained (their list of
roles and so on).
A security context is established for the user
The user proceeds, potentially to perform some operation which is potentially protected by an access control mechanism which checks the required permissions for the operation against the current security context information.
The first three items constitute the authentication process so we'll take a look at how these take place within Spring Security.
The username and password are obtained and combined into an instance
of UsernamePasswordAuthenticationToken (an instance of the
Authentication interface, which we saw earlier).
The token is passed to an instance of AuthenticationManager for
validation.
The AuthenticationManager returns a fully populated Authentication
instance on successful authentication.
The security context is established by calling
SecurityContextHolder.getContext().setAuthentication(...), passing
in the returned authentication object.
SecurityContextPersistentFilter
The name is quite explicit. The SecurityContextPersistentFilter interface purpose is to store the security context in some repository.
To achieve this task, the filter delegates the job to a SecurityContextRepository interface.
Spring provides a default implementation for this interface: org.springframework.security.web.context.HttpSessionSecurityContextRepository. This is quite self-explanatory. The repository for the security context is simply the current user HTTP session.
Below is the XML configuration for the SecurityContextPersistentFilter
<!-- Filter to store the Authentication object in the HTTP Session -->
<bean id="securityContextPersistentFilter"
class="org.springframework.security.web.context.SecurityContextPersistenceFilter">
<property name="securityContextRepository" ref="securityContextRepository" />
</bean>
<bean id="securityContextRepository"
class="org.springframework.security.web.context.HttpSessionSecurityContextRepository" />
LogoutFilter
The LogoutFilter is in charge of logging out the current user and invalidating the security context. The task of invalidating the HTTP session is again delegated to another actor, the SecurityContextLogoutHandler.
This handler is injected in the LogoutFilter constructor:
<bean id="logoutFilter"
class="org.springframework.security.web.authentication.logout.LogoutFilter">
<constructor-arg value="/pages/Security/logout.html" />
<constructor-arg>
<list>
<bean class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"/>
</list>
</constructor-arg>
<property name="filterProcessesUrl" value="/j_myApplication_logout"/>
</bean>
<constructor-arg value="/pages/Security/logout.html" /> - it defines the URL of the logout page.
The SecurityContextLogoutHandler is injected as constructor argument at <bean class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"/>
The HTML URL for the logout action is define by the filterProcessesUrl parameter at <property name="filterProcessesUrl" value="/j_myApplication_logout"/>
Resource Link:
https://doanduyhai.wordpress.com/2012/01/22/spring-security-part-i-configuration-and-security-chain/
https://doanduyhai.wordpress.com/2012/02/05/spring-security-part-ii-securitycontextpersistentfilter-logoutfilter/
http://shazsterblog.blogspot.com/2014/02/spring-security-custom-filterchainproxy.html
http://docs.spring.io/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/context/SecurityContextPersistenceFilter.html
clearAuthentication flag was added in this commit with comment
Previously there was a race condition could occur when the user attempts to access
a slow resource and then logs out which would result in the user not being logged
out.SecurityContextLogoutHandler will now remove the Authentication from the
SecurityContext to protect against this scenario.
It fixed this issue (same issue on github). Quote:
HttpSessionSecurityContextRepository restores authentication to the session if session is invalidated from another thread if SecurityContextPersistenceFilter execution takes significant amount of time.
I am using Spring + JSF + DWR framework + GWT event service (ajax push). In any time there is at least one thread waiting at the server side for push events. This request is handled by SecurityContextPersistenceFilter which remembers the authentication at the moment of request's arriving to the server. If during the processing of this filter the session is being invalidated (by clicking logout in another tab of invalidating session by id from admin area) then HttpSessionSecurityContextRepository put the outdated authentication to the new session(which is created by JSF framework, so the session is changed during the processing of SecurityContextPersistenceFilter ).
This easily reproducable if some processing delay is inserted to SecurityContextPersistenceFilter.
SaveToSessionResponseWrapper should remember the initial HttpSession and check if the original session was invalidated so it won't set the current authentication to the new session.
http://docs.spring.io/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
Storing the SecurityContext between requests
Depending on the type of application, there may need to be a strategy in place to store the security context between user operations. In a typical web application, a user logs in once and is subsequently identified by their session Id. The server caches the principal information for the duration session. In Spring Security, the responsibility for storing the SecurityContext between requests falls to the SecurityContextPersistenceFilter, which by default stores the context as an HttpSession attribute between HTTP requests. It restores the context to the SecurityContextHolder for each request and, crucially, clears the SecurityContextHolder when the request completes. You shouldn't interact directly with the HttpSession for security purposes. There is simply no justification for doing so - always use the SecurityContextHolder instead.
Many other types of application (for example, a stateless RESTful web service) do not use HTTP sessions and will re-authenticate on every request. However, it is still important that the SecurityContextPersistenceFilter is included in the chain to make sure that the SecurityContextHolder is cleared after each request.
[Note] Note
In an application which receives concurrent requests in a single session, the same SecurityContext instance will be shared between threads. Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread is running. If you just use SecurityContextHolder.getContext(), and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. You can customize the behaviour of SecurityContextPersistenceFilter to create a completely new SecurityContext for each request, preventing changes in one thread from affecting another. Alternatively you can create a new instance just at the point where you temporarily change the context. The method SecurityContextHolder.createEmptyContext() always returns a new context instance.
The SecurityContextLogoutHandler invalidates the Servlet session, in the standard Servlet way, calling the
invalidate method on the HttpSession object and also clearing the SecurityContext from Spring Security. SecurityContextLogoutHandler implements the LogoutHandler interface
Traditionally in Java web applications, user session information is managed with the HttpSession object.
In Spring Security(session clearing), at a low level, this is still the case ,
Spring security introduced new way of handling sessions or user session information.
In an application using Spring Security, you will rarely access the Session object directly for retrieving user
details. Instead, you will use SecurityContext (and its implementation class) and SecurityContextHolder
(and its implementing classes). The SecurityContextHolder allows quick access to the SecurityContext, the
SecurityContext allows quick access to the Authentication object, and the Authentication object allows quick
access to the user details.
for example following programing illustrates accesing authentication object and displaying message
#Controller
#RequestMapping("/admin")
public class AdminController {
#RequestMapping(method = RequestMethod.POST, value = "/movies")
#ResponseBody
public String createMovie(#RequestBody String movie) {
System.out.println("Adding movie!! "+movie);
return "created";
}
#RequestMapping(method = RequestMethod.GET, value = "/movies")
#ResponseBody
public String createMovie() {
UserDetails user = (UserDetails)SecurityContextHolder.getContext().getAuthentication().
getPrincipal();
System.out.println("returned movie!");
return "User "+user.getUsername()+" is accessing movie x";
}
}
once authentication is done it creates a new session is created;
Once session is created it contains information of user .on logout u need
not only to invalidate session but also need to clear the session information
by default in
`isInvalidateHttpSession(`)
checks whether session is valid or not
if session is valid
setInvalidateHttpSession(boolean invalidateHttpSession)
is called . howver invalidateing session object invalidates but session object still contains information.
to clear session information u need to call
setClearAuthentication(boolean clearAuthentication)
method thus becomes thread safe if u dont it third method it information can be retrieved at low level
Related
I have created CAS server and the CAS Client application. Basically the authentication of a service app has been done using service ticket and proxy ticket validation. In this case, initially I validate a particular user by validation of the service ticket and then authorize a user for a particular app by generating a proxy ticket using the service ticket. In this case I am able to successfully validate the service and proxy tickets in the service application. The problem that I am facing is that once I validated the user I can retrieve the user information via Assertion object using the following code segment.
Assertion assertion = serviceTicketValidator.validate(serviceTicket);
Here the serviceTicektValidator object is a class that I have written by implementing the Cas20ServiceTicketValidator valdation functions. Here the assertion object is set to the SecurityContextHolder as follows.
CasAssertionAuthenticationToken token = new CasAssertionAuthenticationToken(assertion, serviceTicket);
SecurityContextHolder.getContext().setAuthentication(token);
Here this way, I am setting the authentication object. But the fact is once the request is changed or consider a new request, in the SecurityContextPersistenceFilter filter class in the following code segment the SecurityContext object is being cleared. So once a new request is fired the already stored authentication detail is vanished from the SecurityContextHolder object. So once every request the authentication details has to be set, because a particular service or proxy ticket can only be validated once. Here the approach taken by me is keeping the Assertion object and ticket generated in the Session and then at the beginning of this class (or actually I am doing all these in a filter) I check whether these values are in the session and again at each new request the CasAssertionAuthenticationToken is set to the SecurityContextHolder.
HttpRequestResponseHolder holder = new HttpRequestResponseHolder(request, response);
SecurityContext contextBeforeChainExecution = repo.loadContext(holder);
try {
SecurityContextHolder.setContext(contextBeforeChainExecution);
chain.doFilter(holder.getRequest(), holder.getResponse());
} finally {
SecurityContext contextAfterChainExecution = SecurityContextHolder.getContext();
// Crucial removal of SecurityContextHolder contents - do this before anything else.
SecurityContextHolder.clearContext();
repo.saveContext(contextAfterChainExecution, holder.getRequest(), holder.getResponse());
request.removeAttribute(FILTER_APPLIED);
if (debug) {
logger.debug("SecurityContextHolder now cleared, as request processing completed");
}
}
The application is working the expected way, but I want to know whether there is a better way to implement this by using advanced techniques in Spring Filters or any other option. I also considered local storage of tickets and authentication information, but I want to do this within Spring Application even without using this session storage mechanism. I want to know whether this is possible or not?
I understand what #Secured DOES but not really sure HOW it does it.
Can someone explain how #Secured grabs the roles? Is it getting it from the authorities-by-username-query? Can I put any String in the params as long as it's in the database?
User's roles are stored in SecurityContext, or to be more specific in Authentication object that is stored in the SecurityContext. When you authenticate, the authentication information is loaded and stored in the security context. The roles can originate from database, depending on your configuration. In your case they are loaded using authorities-by-username-query query.
When the security interceptor processes the authorization (for instance method-level authorization using #Secured annotation) it determines whether the user should be able to access it based on the Authentication stored in the context.
To better understand what happens under the hood, you should look at the Spring Security Filter chain and Architecture section of the reference guide.
SpringSecurity provides and awesome AOP way of securing methods in
Java Application by using #Secured. Spring logically ORs the roles
listed in #Secured annotation. The collection of GrantedAuthorities is obtained from SecurityContextHolder.getContext().getAuthentication().getAuthorities()
AbstractSecurityInterceptor is the abstract class that implements
security interception for secure objects.
Obtain the Authentication object from the SecurityContextHolder.
Determine if the request relates to a secured or public invocation
by looking up the secure object request against the SecurityMetadataSource.
For an invocation that is secured (there is a list of
ConfigAttributes for the secure object invocation):
If either the Authentication.isAuthenticated() returns false, or the alwaysReauthenticate is true, authenticate the request against the configured AuthenticationManager. When authenticated, replace the Authentication object on the SecurityContextHolder with the returned value.
Authorize the request against the configured AccessDecisionManager.
Perform any run-as replacement via the configured RunAsManager.
Pass control back to the concrete subclass, which will actually proceed with executing the object. A InterceptorStatusToken is returned so that after the subclass has finished proceeding with execution of the object, its finally clause can ensure the AbstractSecurityInterceptor is re-called and tidies up correctly using finallyInvocation(InterceptorStatusToken).
The concrete subclass will re-call the AbstractSecurityInterceptor via the afterInvocation (InterceptorStatusToken, Object) method.
If the RunAsManager replaced the Authentication object, return the SecurityContextHolder to the object that existed after the call to AuthenticationManager.
If an AfterInvocationManager is defined, invoke the invocation manager and allow it to replace the object due to be returned to the caller.
Look at the source code for more understanding.
AccessDecisionManager is the interface which is implemented as AffirmativeBased, ConsensusBased or UnanimousBased orchestrates the voters and asks each in turn whether the requesting user should be let through the #Secured annotation or denied.
I have small application using JSF 1.1. It is using NTLM for authentication.
What is the best approach to store the logged in user_id, so that could be used in application across all java classes, user_id would be used in almost all jsf pages corresponding java classes.
Any help is highly appreciable.
Thanks
store it in the web session :
session=FacesContext.getExternalContext().getSession();
session.setAttribute("user_id",user_id);
This would depend on how you are performing authentication. If you are delegating the authentication process to the container, by using FORM, BASIC or DIGEST authentication, then you can obtain the Principal object associated with the current request using the following snippet:
Principal user = FacesContext.getCurrentInstance().getExternalContext().getUserPrincipal();
The name of the user in the realm can be obtained using the user.getName() method. Under the hood, the container stores the Principal object in the HttpSession instance, but this is not accessible as an attribute using the HttpSession.getAttribute(...) method, in most containers.
The Principal object is also automatically propagated by the Servlet container to the EJB container, when the business method of an EJB is invoked, and you can access it using the SessionContext interface. In an EJB, you can perform the following, to obtain a reference to the Principal:
#Resource
private SessionContext ctx;
public void businessMethod()
{
Principal user = ctx.getCallerPrincipal();
...
}
If you are not delegating authentication to the container, and instead, you are performing authentication using your own scheme, then you must store the reference to the identity of the user in the HttpSession object upon successful authentication, and you must clear this upon session invalidation. Storing it in other scopes is not recommended, as only a HttpSession object has the same lifetime as a user's session with the application.
i need to invalidate ( or kick ) user session. the application only limit user login only one user per container.
i try to call removeSessionInformation from session registry, its done to unlock the user. so the other user can login with the kicked session user name.
but SessionContextHolder at that user that been kicked is still. so they still have the same authority to access the protected page.
how to invalidate or remove Principal of SessionContextHolder from specified session registry information?
ps : in my old application, i give one variable in UserDomain (UserDetails) that hold HttpSession. and when they need to kick the user, i just invalidate HttpSession from specified UserDomain. the but i don't know how to do it in spring (its more likey to remove Principal of SessionContextHolder than HttpSession). implementation is almost the same with how SessionRegistryImpl do in spring.
You may like to consider Spring Security Concurrency Control. You can configure this to limit the number of concurrent sessions per user and expire (kick) existing sessions if that number is exceeded.
Spring Security Session Management
This is a snippet of our configuration (Spring 3):
<http>
...
<session-management>
<concurrency-control max-sessions="1"/>
</session-management>
...
</http>
I'd guess this is the way to do it:
SecurityContextHolder.getContext().setAuthentication(null)
From the SecurityContext.setAuthentication(Authentication) Javadocs:
Changes the currently authenticated
principal, or removes the
authentication information.
Parameters: authentication
- the new
Authentication token, or null if no
further authentication information
should be stored
You can also do the following to clear the SpringSecurity Session:
SecurityContextHolder.clearContext()
This is extracted from my application-security.xml
class="org.springframework.security.web.authentication.session.ConcurrentSessionControlStrategy"
p:maximumSessions="1" <br>
**p:exceptionIfMaximumExceeded="true"** >
<constructor-arg name="sessionRegistry" ref="sessionRegistry" />
try adding the line in bold letters after the maximum sessions number
I have a custom-authentication-provider defined in my Spring Security configuration. This class implements AuthenticationProvider, and I can successfully log in using the form defined on my page. The issue is I want to call this class not just on the login page, but from the registration page as well.
The registration page uses a different command class and collects more information than the login form. Right now, when the user registers, I call the appropriate controller, add the record to the database and they can then log in but they aren't logged in automatically. As they've just given me their user name/password on the registration page, can I then pass this to the custom AuthenticationProvider class so they are also logged in?
I've tried creating an org.springframework.security.Authentication class in the registration controller and calling the authenticate method on my customer AuthenticationProvider class, and this doesn't error out, but the user isn't logged in. Do I have to call a method higher in the Spring Security filter chain to accomplish this? Should I redirect the controller to the j_spring_security_check URL? If so, how would I pass the username/password?
You need to put the result of AuthenticationProvider.authenticate() into SecurityContext (obtained from SecurityContextHolder).
Also be aware of AuthenticationSuccessEvent - if your application rely on this event (some Spring Security features may use it, too), you should publish it (you can obtain the default AuthenticationEventPublisher via autowiring). It may be useful to wrap your authentication provider with ProviderManager, it publishes the event automatically using the given publisher.
The problem you are having is that although you have successfully authenticated the user you have not stored the result of this authentication in the user's SecurityContext. In a web application this is a ThreadLocal object which the SecurityContextPersistenceFilter will use to store the user's credentials in the HTTPSession
You should also avoid authenticating directly with your custom authentication provider if you can. Your xml configuration should contain an AuthenticationManager which your custom authentication provider has been wired into. For example,
<bean id="customAuthenticationProvider"
class="com.foo.CustomAuthenticationProvider">
<property name="accountService" ref="accountService"/>
</bean>
<security:authentication-manager alias="authenticationManager">
<security:authentication-provider ref="customAuthenticationProvider"/>
</security:authentication-manager>
If you wire the authenticationManager into your registration service and authenticate using that it will additionally,
allow you to swap in/out additional authentication providers at later points
publish the authentication result to other parts of the Spring Security framework (eg success/failure Exception handling code)
Our registration service does this as follows
final UsernamePasswordAuthenticationToken authRequest = new
UsernamePasswordAuthenticationToken(username, password);
final Authentication authentication =
authenticationManager.authenticate(authRequest);
SecurityContextHolder.getContext().setAuthentication(authentication);
We also optionally store the authentication result at this point in a remember-me cookie using the onLoginSuccess() method of TokenBasedRememberMeServices.