We Keep Coding

Spring boot security avoid specific user session expire

Hello everyone I've got my spring boot application on Apache Tomcat server and it works fine. But now I need to avoid session expiration for an specific user. How could I do that? I've been searching ways and found that handler interceptor could be useful for session management but I'm not sure.
Thanks in advance!

I am afraid there is no simple way to do it. Expiration timeout is common for all users of your application and controlled by the application server. In order to have a different timeouts for different users you should:
implement some session wrapper over a native server session;
set expiration timeout for native server sessions to the longest time that you will give to one of your user sessions;
manage expiration timeout of your session wrappers by your own.
EDIT: In my opinion the best way to solve this issue is reconsidering of client's requirement (immortal user with admin rights is a bad idea for your application). Anyway customizing of security related parts of application is always risky and you should really know what you do.

Session Management in microservices

We have the following setup.
STM (Stingrey Traffic Manager) does load balancing + session stickiness
Weblogic 'cluster'
Auth handled by a third party tool
Therefore I do not have to worry about session with regards to horizontal scaling/ running multiple instances of the application. STM/ Weblogic cluster makes sure that the subsequent request come to same managed server.
What we currently have is a monolithic application and we are trying to move to microservices. Also we do not wan't to move out of current infrastructure (i.e. STM/ Weblogic cluster/ Auth tool). What we have planned is:
A Gateway WAR which routes requests to other microservices
N x Microservices (WAR) for each functional sub-domain
Only the API Gateway receives user requests and other microservices are not accessible from outside
So my question is
Should API Gateway be state-full while other microsevices are stateless?
If so, how should the user session data be shared between API Gateway and microservices?
Please suggest any better alternatives and resources/links as well. Thanks.

Let me share my opinion.
First of all, if you can keep your application stateless, by all means do so :)
It will be the best solution in terms of both performance and scalability.
Now, if its impossible, then you should maintain some distributed session management layer.
The gateway responsible for authentication could generate some unique session identifier which could later be used as a key.
This key could be propagated to all the microservices and be a part of the API or something.
In order to access the session, the microservice could 'get' value by key and work with it.
In terms of implementation: I would take a look on NoSQL solutions. Some of them that can suit your need are:
Redis. Take a look on ''hset'' there
Hazelcast. Its more a in-memory grid but if the solution is java only, you can also implement the required functionality
Memcache.d. It will give you an old good map, just distributed :)
There are also other solutions I believe.
Now, the performance is crucial here, otherwise the whole solution will be just too slow. So In my understanding, using an RDBMS would be not be good here, moreover potentially it would be harder to scale it out.
Hope this helps

1)Should API Gateway be state-full while other microservices are stateless?
Yes, As in 12 Factor App guide lines all the services should be stateless.
2)If so, how should the user session data be shared between API Gateway and microservices?
Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.

Manage session across two app servers

I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.

You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.

session migration/replication in tomcat

I have N number off application servers all behind a hardware load balancer.Now i want to make these app server session aware?
If i create a session on one appserver other app server will not be aware of it.After googling i found 2 approaches
1)Generate a random String .Put this randomString in cookies and store these in Db table with creation time.Very time when request comes in check this db table.But this opration is heavy
2)Use tomcat session migration?Now am sure if this works correctly .Does this work correctly?
Am using TOMCAT as my web server (Cant use other)
How can i configure tomcat for session migration/replication?Any tutorial?

I am not aware about the session affinity when working behind a hardware load balancer ,However for the scenario that you have mentioned as per your googling results for the 1st part you can use Memcache instead of cookie+database to reduce the operation response time . A simpler approach when using Memcache can be using "memcached-session-manager" .The setup and configuration is easy as mentioned at at http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration .

Session replication is a pretty broad topic. Have you tried the Tomcat built-in replication yet?
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
If that's not good enough for you, you can look for commercial tools like Terracotta Web Sessions. Or you could develop your own session cache around for example memcached.

Session Management of a java base REST web application in a clustered environment

I have this requirement, i need to implement java base RESTful web service in a clustered environment. my problem is how do i manage the user sessions here. Once a user logged in, he should be able to perform all the available actions without a problem, also a user should be able to keep a shopping cart for him. What is the best approach for this? Any code samples to do this? please note main factors to be identified are,
RESTful web application in a clustered environment.
Multiple clients will be used this application. (Eg: Android, Apple, Web..etc)
user should be able to keep a shopping cart (Dont know whether this violates the RESTful concept)
Runs in Jboss 6.0.0

RESTFul applications don't use sessions so there should not be any problems using a clustered environment. RESTful applications send authentication credentials on every request.

There's no problem with having a shopping cart in a RESTful web service. It's just that the shopping cart won't be stored with the session as some typical applications do. In this case, you'll want a shopping cart resource:
/app/rest-api/shopping-carts/204314
All devices could access this resource and see the same data. Since the web server is stateless (shopping carts are stored in a database), clustering isn't a problem. I don't know of any particular problems JBoss would have doing this. I would guess none, since JBoss implements all the functionality from the Servlet spec (or at least enough to facilitate what you need here.
In terms of authenticating users and associating them with carts, that is a much bigger topic, with a lot of dependencies on information you haven't provided. For example, do you have access to an OAuth provider? Alternately, are you considering the OpenID route? Is user authentication information already stored in your application somewhere? what does that look like?