Develop Reference

Invalidate user sessions on multiple servers

I've a Grails application which is deployed on two servers, and the requests to those servers are controlled by AWS load balancer using sticky session.
A user can have concurrent sessions, so the user might be logged in and having a session on Server A, similarly the user might have a session on Server B.
If a user changes their password, I want to invalidate all the sessions of that user. I'm able to do that on one server using SessionRegistry. How do I kill the same user's session on the other server.

If you're site is API-driven and you are using a token, all you would have to do is invalidate their token; everytime they are requesting anything via an api or that requires checking their roles, it will check the token in your DB (or the DB of the Identity Management SAAS you use) and removing that would make the very next refresh of the page ask them to log back in.

Tomcat logs user out during session failover event and restarts

We've implemented session replication using Redisson, but we noticed that if we intentionally fail a node, the user's sessions do get replicated, but they're logged out when they're restored on the new server.
This answer here: Restore user login after tomcat 7 restart alludes that using the JAASRealm will allow someone to stay logged in across a restart.
To test this, I setup the JAAS Realm in Tomcat successfully using the properties login module. However, when I restart, the user gets logged out. I do see my sessions get written to disk by tomcat in it's work directory.
Is there a way to make this work properly so the user doesn't get logged out during a failover event? More importantly, is there a technical or security reason for this?
If you look at the Tomcat code, they actively try and avoid serialization the Principal:
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L1559
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L234

WSO2 - Restrict concurrent login with same user simultaneously

I've integrated Java jar based application with WSO2 identity server, this application has login portal whereas it is possible to login with same user simultaneously through different systems and browser. Is there any way to restrict Simultaneous or concurrent login at WSO2 server end. if there is any way to prevent concurrent logins with same user then please let me know. thanks

With IS 5.3.0 you can find all the login sessions of a given user. To get this done you need to write an interceptor for the login flow and check whether that user has a login session already - and if so fail the authentication.

What is different between "Remember me functionality" and 'Keep me logged in" functionality?

I want my website to have a checkbox that users can click so that they will not have to log in each time they visit my website.

Remember me
Remember-me authentication refers to websites being able to remember the identity of a principal between sessions. This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place. Spring Security provides the necessary hooks for these operations to take place and has two concrete remember-me implementations. One uses hashing to preserve the security of cookie-based tokens and the other uses a database or other persistent storage mechanism to store the generated tokens.
Keep me logged in
When checked, the option Keep me logged in allows you to force your browser to remember your credentials to be automatically connected when reaching the login page. By default, your credentials are stored for 2 weeks. After this period, you will have to log in again.

Authentication Strategy for GAE

I have an application deployed to Google App Engine. Within the application, there are 2 roles: standard user, and administrator. I have form based authentication setup, and the URL's that require authentication (for example /admin and /account) are setup to require any role (*), just so I can be sure that Google has authenticated them. I have a filter setup for the admin path as well as the account path that talks to backend business logic to see if the user has an account within my application before forwarding them to the page they requested, or redirecting if necessary.
This seems cumbersome, in that for each request, the filter uses the UserService to get the google user in order to determine whether or not the person authenticated by google has an account within the application. I know that within the context of an application deployed to a traditional application server, I could actually define the application level role required to access a url, and since the application server would know about the roles/users for the application, that would be sufficient, but since google is handling the authentication, would I be correct in assuming that I have to handle the access requirements on a per request basis, as I am now with the use of filters? I chose to use filters to try to keep the actual servlet 'cleaner', so that I know that when a client request reaches the servlet, they have been authenticated and are authorized to access those resources.
Would it be wise to carry that data around (whether a user is authenticated and whether or not they are an admin or standard user) in a session? That's the only other alternative I can come up with. I'm not sure how expensive it is to access the UserService for every single request, because that is in turn accessing the datastore. I would imagine there has to be a better way to handle authentication.

Not really sure if it's an optimal solution but what we do now is store a User session (our own implementation, not GAEs) and we cache it aggressively using Objecitfy's cache feature. That way we only hit the datastore on login/logout and most queries after that are virtually free (because of the use standard session time on our app, cache flush is not really a concern)