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
Related
I've been attempting to setup springboot2.5+ with the new saml2login implementation, but I'm finding it very difficult (due to lack of documentation and old documentation from the spring-security-saml extension) to do it in a stateless manner.
Has anyone been able to get springboot saml2 working stateless? I can't seem to figure out how to get my ACS (Assertion Consumer Service) filter from spring security to return a custom cookie with a redirect instead of a jsessionid.
Any help or insight would be awesome. Right now, I have a hack-y work around where I'm leaving sessions on, but attempting to kill the session right after SSO via SecurityContextHolder.clearContext(), but this is causing other issues.
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 a beginner and i read some part of Spring Security.
from docs,
Spring Security provides you with a very flexible framework for your
authentication and authorization requirements,
But i didn't get the actual goal behind Spring Security. Why i need spring security as i can achieve same thing by simple java filter manually.
What Spring Security make sense to worth using it?
Appreciate if anyone can explain in simple words and mention some use cases for that.
refer
http://docs.spring.io/spring-security/site/docs/3.2.x/reference/htmlsingle/faq.html#faq-web-xml
Spring Security isn't only for protecting pages it can also protect methods, do ACL on your domain objects. Prevent (or at least make it more difficult) to do session hijacking, it also has support for concurrent session usage (a single user can login only max x times at once).
The current release also has support for security headers and out-of-the-box CSFR protection for your forms.
Next to all that it provides, out-of-the-box, multiple ways of storing your security related data be it in files, database, ldap, active directory
Whilst you might be able to do simple protection of pages in a filter it doesn't give you any of the added benefits of Spring Security.
Finally Spring Security has been battle tested and is used by many companies, small to large, whilst your simple custom filter isn't.
I have configured security on the enterprise projects using both the ways: Here is the benefits using Spring Security over writing Filter:
1) Ease to Use & Configure
2) Multiple Auth Provider (i.e. LDAP, SSO, etc)
3) Maintainabilty
4) Ease to implement Session Management
5) Ease to implement Remember Me Functionality
I am new to Spring Security and am mulling over the idea of using it or not in my application.
The requirement is as follows :
In my web application i store a session information inside the database,a key for this is stored in a cookie
2.Now whenever someone tries to access a url which is not according to the flow i want to deny access.
3.Can i use Spring Security for this.
I am using Spring MVC,Mongo DB and MySQL as the develeoment environment.
Regards,
Abhishek
If you're trying to simply control the flow of an application, I'd suggest using Spring Webflow. This allows you to define set flows in a multi-page application.
Spring Security can be used to control flows, but only for access control. It integrates well with Webflow (and with Spring MVC) to ensure you can secure some or all of your flows.
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.