I need to use Concurrent Session Control features of Spring Security. I need to invalidate the previous session of the logged in user(single user sign in). I do not need the feature of authentication and authorization, since it was already implemented by the application using Servlet(Filter) which calls serice layer that calls dao layer(Hibernate).
Please guide me how to implement Concurrent Session Control without authentication and authorization.
Thanks,
balachandar
One option (hack) would be to use Spring's pre-authentication feature. i.e. you would perform your authentication in your filter and set an attribute on the request object which is the username. The request would then be passed down to Spring and Spring where the concurrent session control feature could be enabled.
But really the best option would be to implement concurrent session control in your filter. You could even "borrow" some code from the spring source.
Short answer: you can't unless you refactor your application to use spring-security fully.
Slightly longer answer: you can "fake" a Java EE container login (pre-authenticated). That would entail specifying a login-filter derived from AbstractPreAuthenticatedProcessingFilter in your spring security http configuration. For instance, you could wrap your request in your filter and add a header values and use the RequestHeaderAuthenticationFilter, or you could write your own that pulls the principal from a request attribute you set on the request in your own login filter. Combine with a PreAuthenticatedAuthenticationProvider.
Slightly longer answer #2: you could use an allow-all kind of setup where you configure spring-security with session concurrency as usual but set the access to permitAll for all URLs (is <intercept-url pattern="/*" access="permitAll" />). You would, however, have to implement essentially what the ConcurrentSessionControlStrategy does in your own login logic, to get the sessions registered into the spring security SessionRegistry. You will most likely run into any number of other snags along the way as well.
Note however that since spring-security works on the basis of a servlet filter (not a servlet like Spring MVC), you will need to refactor your own login as a filter and place it before the spring security filter in the chain, if you are to go with some combination of your own auth logic and spring security.
My advice, if you want to leverage spring-security for concurrent session control, you should really go all the way and build your auth on top of spring-security instead of some custom servlet. Don't fight the framework, use it as intended. Or, don't use it at all.
Related
I'm building a simple project management web application and I'm having some problems finding the best practices for storing the current logged user without recurring to spring security.
I was thinking of creating a filter or maybe a interceptor to reduce code but I'm still struggling with how to actually store the user. Is it better to had a specific header to the request or is there a more elegant way to do this?
You can use spring session to maintain the login information in you app in a better way, there are various options available in spring to replace normal HttpSession like Spring Session JDBC.
See Here: https://spring.io/projects/spring-session
I have a single grails (3.3.5) web server, and I am interested in improving the availability and I'd like to add another server and put a load balancer in front of it.
Rather than share sessions between servers, or use sticky sessions, i'd like to know if there is a good way to have a session-less front-end server. I don't use sessions for anything other than using spring-security to validate the session token that it is using to identify the user.
I'd like to find a token based authentication system suitable for the front-end such that the token is safe and sufficient for identifying the current user.
I've seen the grails-spring-security-rest plugin which looks promising, but it seems like everyone is using it for back-end rest api calls. Is it also suitable for front-end authentication when you aren't storing application data in the webapp session?
If you don't use the session objects in your controller then tomcat will not create any sessions for you.
Also you can define your controllers to be
static singleton = true
then they will be instantiated not on per-request basis.
Now, if you still want to use sessions, you can use something like Cookie Sessions and keep your data inside the cookies instead of tomcat's memory.
I haven't used the grails-spring-security-rest, but you should be able to tweak spring-security-core to be session-less. You should set scr.allowSessionCreation to false and use remember-me.
Since Grails is built on Spring Boot, you can access all the features of Spring Session (https://docs.spring.io/spring-session/docs/2.0.x/reference/html5/), which includes the ability to share session data between server instances with some data store instead of keeping it in memory.
In those docs you'll find this pointer to a guide with a Grails 3.1 example that uses Redis as the store. https://github.com/spring-projects/spring-session/tree/2.0.3.RELEASE/samples/misc/grails3
Is it also suitable for front-end authentication when you aren't storing application data in the webapp session?
Yes, you can use JWT tokens in your front-end. You need to properly configure the security filters of your controllers so that they are not using cookie for authentication but they are looking for JWT.
See : http://alvarosanchez.github.io/grails-spring-security-rest/latest/docs/#_plugin_configuration for configuration of endpoints that should validate JWT tokens.
Have a look at https://github.com/hantsy/angularjs-grails-sample/wiki/3-basic-auth for a stateless example with Angular.
I am really new to spring and wanted to make a simple web application that uses JWT based authentication.
I have an endpoint on my server (/token) that returns JWT tokens to my client.
These clients then make requests to my server using that token. I was wondering how I could implement something like this:
#Secured("Admin")
#RequestMapping("/users", method=RequestMethod.DELETE)
public #ResponseBody String deleteUsers(){
...
}
From what I could gather, I would need a filter that would validate my JWT token that is sent along with every request the client makes. Is there any way in which only requests that have a #Secured annotation are passed through that filter?
Spring Security maintains a filter chain internally where each of the filters has a particular responsibility and filters are added or removed from the configuration depending on which services are required. The ordering of the filters is important as there are dependencies between them. If you have been using namespace configuration, then the filters are automatically configured for you and you don't have to define any Spring beans explicitly but here may be times when you want full control over the security filter chain, either because you are using features which aren't supported in the namespace, or you are using your own customized versions of classes.
link
Our Spring Boot 1.3.3 application uses Spring Security. We need to log HTTP requests including requested URL, HTTP verb, processing time, user principal.
This is done using a custom servlet filter.
The custom filter must have higher precedence (i.e. smaller order) than Spring Security filter chain, or else it won't be executed for requests rejected by Spring Security.
But then in the custom filter, HttpServletRequest:getUserPrincipal is always null. It seems that Spring Security removes security information once his security chain is done.
Is there a standard way (meaning without thread local magic) to always get the user principal from a custom filter when using Spring Security?
Thank you for your time.
Well as you are using Spring Security, the principal is likely to be set precisely by the Spring Security machinery. But what's even worse, is that it uses request wrapping, so you will not find the principal neither before calling the FilterChain because it has not been set, nor after because it was set in a HttpServletRequestWrapper that is no longer here.
So IMHO your best choice is to put a custom filter inside the Spring Security chain, just before the ExceptionTranslationFilter, log after chaining and pass along any exception.
I am implementing a Spring Data REST based app and I would like to know if there is an elegant way to implement authentication and authorization rules using this framework or related frameworks.
All HTTP requests to the REST server must carry authentication headers, I need to check them and decide to authorize or not based on the HTTP method and the association of the authenticated user with the resource being requested. For example, (the app is the REST server of an e-learning system), the instructors can access only their own course sections, students can access only the courses sections they are subscribed, etc.
I would like to know if there is a default way to implement authorization in Spring Data REST. If the answer is no, could you make a suggestion for my issue? I am thinking about:
Servlet Filters
Spring Security
Spring Data REST Handlers (how to access the HTTP headers?)
The best bet for you is Spring Security.
That would help you achieve authorization is much simpler manner.
Spring Security would require you an implementation that looks at request headers and performs the log-in operation programmatically.
Refer the accepted answer here.. I had followed the same and implemented the security layer in front of my rest services ( which were build using RestEasy )
RESTful Authentication via Spring
There is an alternate method as well..
Refer
http://www.baeldung.com/spring-security-authentication-provider
In both cases you can disable the session creation by declaring the stateless authentication in spring security, this would help you improve the performance considerably when large volume of hits are made to the state-less REST services..