What are the minimum steps requires to config Spring Security Java to provide a database stored session implementation. Basically I want to use Session ID with Cookies and a JDBC based Session Implementation. It seems that I have to implement a custom Session Registry but could not be sure that what I need extra implementations to provide a database based Session implementation.
(I am using Spring Security RC2)
I have implemented RESTfull distributive system using Spring Security and MongoDB.
Here are filters, config and service.
Please feel free to fork and push.
Rob Winch and M. Deinum clarified my question and explained that currently this is not possible with Spring. However there is an issue related to my question. I have decided to use Servlet API and Container Session Management.
There is a Spring Session project which is being implemented by Rob Winch currently.
Related
We are experiencing an issue in production which seems identical to when we restart our dev boxes and try to authenticate using the token that was generated with the previous instance of our SSO Spring Boot App and powered by Spring Authorization Server.
The error is: Wrong nonce
In production, it looks to occur when our SSO app scales up due to a user spike. We could see this happening at a point with high user activity and we would continually get logged out.
Now, of course we do not want all our active users to suddenly have invalid tokens just because a new instances of SSO is added.
This questions also relates to the currently unanswered, but much older question here: Can Spring Security OAuth2 Authorization Server scale horizontally?
Please advise. It is the number 1 most frustrating issue we are having in production right now and we are not quite sure how to proceed. We are not using any In-Memory implementations of classes.
2022-07-12 - Update: The question was asked "How are we storing the session?"
We are storing OAuth2 authorizations, authorization consents and registered clients in MongoDb.
We implemented OAuth2AuthorizationService, OAuth2AuthorizationConsentService and RegisteredClientRepository
Spring Authorization Server is built on Spring Security (see docs Overview) and does require knowledge of Spring Security (see Getting Help).
In particular, you'll want to review the Authentication chapter of Spring Security documentation. Session management falls under this topic, and if you're using (for example) form login or something similar, you'll almost certainly want to add Spring Session to your server to manage distributed sessions.
You are also likely running into an issue on the client side if you are not managing sessions in a database, so once again looking into Spring Session for the client will help alleviate issues such as the nonce error you mentioned. You will also want to look into the OAuth2 Client documentation and review the core interfaces as you will need to be storing your client authorizations in a database as well.
Steve writes a great response above already and I marked it as the answer.
To answer the title of this question:
Yes, Spring Authorization Server can easily be scaled to include multiple instances without suffering from the original misconfiguration issue we were experiencing.
Spring Authorization Server does not have any magic tools to persist a session across instances. It is reliant on session management being configured correctly. We use Spring Session backed by MongoDb for our purpose.
Session validity best practices is probably something that should be addressed and whether some of them should have the same timeout values.
Servlet session timeout
Spring Session timeout (this overrides 1 when present)
Remember me timeout
Token timeout
We are still figuring out / playing with what these values should be and have found no document or article that speak of one best way of doing things.
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
A simple question, what is the use of Spring session where I can do a login with session using spring security?
What feature can spring session offer?
To put it simple, Spring Session project provides infrastructure for managing user's session.
Most notably, this includes replacing the HttpSession implementation provided by your Servlet container (e.g. Tomcat) with an implementation provided by Spring Session which is then persisted using SessionRepository implementation of your choice (Redis, Gemfire, Hazelcast, JDBC, Mongo are supported backends in current 1.2.0.RELEASE). This ensures your sessions are stored in container/platform agnostic way and makes session clustering very easy.
Additionally, Spring Session provides some other nice features such as:
configurable strategies for correlating user's requests with a session (either cookie or HTTP request header based)
support for multiple sessions in a single browser instance
WebSocket integration, meaning the HttpSession is kept alive when consuming only WebSocket
ability to retrieve all the sessions for a given user
For more information please take a look at Spring Session's user manual as it contains detailed guides which describe the most common use cases.
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 need to have web application which actually consist from few separate wars unified into same navigration bar on UI, i need to have all system secured but have authentication only to main web application and after automatic propagation of this security context to sub web applications. I'm using spring security, could someone help me with advice? thanks
This can be achieved by following approach. In Spring, SecurityContext by default is stored in HttpSession. Instead you can configure it to store in some shared repository.
So, configuration should be changed to use your own SecurityContextRepository implementation instead of HttpSessionSecurityContextRepository. Once configured, the security framework will look at the Repository which is available to all your web applications.
The Repository can be either a database or a cached server.
Spring Security stores the login data in the http session. So what I would try is to share the session between the applications.
It seams that this is possible (in Tomcat) by using the Single Sing On attribute.
But be warned, sharing the session between two applications is not without danger. See this Stack Overflow question.