I've followed Spring Security's instructions and managed to authenticate my users using JDBC in a Spring Boot project with "Remember Me" feature enabled (and setAlwaysRemember(true)). The "Remember Me" cookie gets created in the client's browser and the Token gets inserted into the "presistent_logins" table without fail.
But here comes the dilemma, When the client closes the browser, the "Remember Me" cookie gets removed automatically, which somehow makes all my effort effectless.
what would be the point of having Remember Me feature, if the cookie which is an essential requirement, gets removed on every browser closed event. Therefore, the user has to do the login all over again.
Here is a picture that shows the remember me cookie has been created after a successful login.
Do I have to take some special measures to make sure that the cookie gets preserved in the browser?
Chrome >>
Firefox >>
It's not the browser who is clearing the remember-me cookie. It's your spring app which tells the browser to clear that cookie (by giving an old expiry time).
So why does spring do that?
Because internally spring is throwing BadCredentialsException. You should debug RememberMeAuthenticationProvider class to make sure why it's throwing that exception.
In my case, the remember-me secret key was different than the one I used in my PersistentTokenBasedRememberMeServices class.
So please debug your application to find out the root cause of it...
Finally had to use normal mode of Remember Me feature (not DB persistence mode) in order to have this working. :(
When I use DB to persist session information, upon closing the browser, the "remember-me" session vanishes somehow!
Related
I have several apps deployed in Tomcat 7, and use Keycloak to manage user login and logout of these apps. Logout does not work i.e., does not log the user out and redirect to Keycloak's login page. Then I found the JSESSIONID cookie is still present, once I deleted the JSESSIONID cookie, the logout link works as expected. So I tried to disable Tomcat's session by putting
<%# page session="false" %>
in the header of my apps' JSP pages. Unfortunately, this still does not seem to disable Tomcat's session, I still see JSESSIONID cookie present. I am wondering if anyone has a solution to this problem? I believe the presence of the Tomcat session interferes with the Keycloak's SSO session, and causes Keycloak logout to not work. This has to be a common problem Keycloak users encounter, Tomcat is so widely used for web apps.
Would appreciate any tips on how we should handle this!
I don't have specific experience with Keycloak, however, there's a principle that applies to most if not all Single-Sign-On (or external authentication) solutions:
SSO identifies a user and removes the burden of knowing passwords from typical applications. When a user signs in, an application server is often detached from the actual SSO system, thus it will need to cache the user once they're identified, just as if the user identified itself with a classic login.
On the logout side, you can either log out of the application itself (tomcat in this case) or you can log out of the SSO system (which seems to be what you're doing here). With the later approach, you're running into the problem of "Single Sign Out": Logging out of the SSO system should invalidate all sessions that once were initiated with the associated login. As I know it, the SSO system needs to keep track of all of the systems that have signed on through it and trigger an explicit logout there.
I can't tell you how to implement this in Keycloak, but hope that the general principle helps guiding you towards the solution:
The use or non-use of a session on Tomcat's side has nothing to do with the problem: You might have applications that legitimately store information in a session in addition to the signed in user - those applications should continue to work even if you're not comparing passwords in tomcat itself.
Edit, after your comment:
If this one page doesn't trigger the use of a session, any other code (e.g. the code that processes your login) still might trigger a session and then later delegate to the page that doesn't want to use a session.
I'd expect that you'll have to disable sessions in Tomcat's configuration e.g. through providing a custom "Manager" implementation. It looks like the default ones do not expect you to completely ignore sessions. As I've outlined above, I'd also expect sessions to be required even if you're not logging in through Tomcat itself.
Another way to avoid sessions (this is the indicator why I don't expect "no session" config to work) is to avoid calling any method on request/response that would trigger the automatic creation of a session. And it seems that you have such a method somewhere in your app.
(someone correct me if I'm wrong. This is mostly my educated expectation as I've never looked at this requirement)
Currently I know that my setup is working because I was able to login properly using the basic HTTP authentication.
I used these properties:
security.basic.enabled=true
security.user.name=user
security.user.password=1qaz2wsx
security.user.role=USER
However, I want to relogin again. I tried clearing cookies (I assumed it was saved there), I checked my local/session storage and cookies in Chrome dev tools but it was blank.
I tried accessing my site in incognito and it asks me to login (for the first time since I only logged in to Chrome non-incognito).
How do I "kill" my session in Spring Security?
If you use basic authentication, the browser stores the authentication until you close it (or exit the incognito mode, if you used it). There is no possibility to delete the session on server side, since the browser would just reauthenticate. If you want to be able to logout, use form login.
I have a Spring MVC App and I have an issue with invalidated sessions.
The app performs AJAX requests that are all authenticated/tied to a session (hold a JSESSIONID)
So here's what happens. Let's say I'm in the app authenticated with a session. If I go into Tomcat and invalidate that session, then the next time an HTTP request gets made, Spring forwards me to the login page. Once I login again, Spring authenticates me fine, but then a number of my AJAX requests get HTTP 403 errors, continuously.
If I go into the HTTP Headers of the requests that get the 403s, I notice they have 2 JSESSIONIDs, one of the authenticated session, the other one of a session that holds only this attribute:
SPRING_SECURITY_SAVED_REQUEST DefaultSavedRequest[<OLD URL>]
So these sessions are not authenticated sessions so they are causing Spring to return a 403.
The issue is that this persists until I kill the browser (on some mobile devices that doesn't even work, and I have to go into settings to clear the browser cache).
Any suggestions?
this is a big problem because it's happening when Sessions invalidate themselves because of TTL, and we're stuck with users who get booted out, log back in and still get 403s, forever, until they clear the cache.
One thing to note is that Spring Security invalidates the existing session when you login and creates a new one, copying the contents of the old one across. This is intended to create a new session identifier to avoid session fixation attacks. You can try disabling this feature to see if it is related to your problem. It sounds like these are the two sessions you are talking about.
However if there are two JSESSIONID headers in the request then it sounds like a problem on the client side. You should work out why your client is sending two values. Also, it sounds like there may be an issue with Tomcat on the server side if you are still able to read the contents of the previously invalidated session.
Also check that Tomcat isn't sending two JSESSIONID values in the login response. There was an issue ages ago where it was doing just that, but it's unlikely you are running such an old version of Tomcat.
I have a grails server and an iOS client that communicate over HTTPS via POST messages. I'm using PersistentTokenBasedRememberMeServices to ensure that the user doesn't have to enter his password all the time. This doesn't seem to work as the session is lost continuously and the user has to login again. The server logs show that a CookieTheftException has occurred with message "Invalid remember-me token (Series/token) mismatch".
Not all server actions require a logged in user. Some can be accessed anonymously and this may be the root of the problem. When the user accesses restricted server actions, the session is maintained, but not when accessing unrestricted actions.
Here's my config in Config.groovy:
grails.plugins.springsecurity.rememberMe.cookieName = 'SomeRememberMeName'
grails.plugins.springsecurity.rememberMe.persistent = true
grails.plugins.springsecurity.rememberMe.alwaysRemember = true
grails.plugins.springsecurity.rememberMe.persistentToken.domainClassName = 'com.myapp.PersistentLogin'
grails.plugins.springsecurity.rememberMe.tokenValiditySeconds=31*24*60*60
I added some traces in the iOS client and noticed a couple of things. First of all the JSESSIONID cookie doesn't have an expiration time, which means it isn't saved in the client like the rememberMe cookie. Can I force it to have an expiration time or is that even a good idea? Secondly I noticed that sometimes the rememberMe cookie that I receive from the server is empty. That may be just because a CookieTheftException was thrown.
Since all of the post message bodies are encrypted with 256-bit AES, I'm not really worried about cookie theft at this time. I just need to get this to work.
I tried adding the following to my config to ensure that the session would be always updated even when accessing unrestricted actions:
grails.plugins.springsecurity.useSessionFixationPrevention = true
grails.plugins.springsecurity.SessionFixationPrevention.migrate = true
grails.plugins.springsecurity.SessionFixationPrevention.alwaysCreateSession = true
I don't even know what these all mean. I just liked the "alwaysCreateSession" part and figured that I need to enable session fixation prevention in order for that setting to have any effect. Will it still always create a session if I set useSessionFixationPrevention to false?
Any help is appreciated.
If you are using PersistentTokenBasedRememberMeServices, your "remember me" token will change after every HTTP request.
Unfortunately that means that requests will only authenticate if your browser makes exactly one request at a time, and browsers often don't do that. If there are 4 few images on a page, the browser will send out 4 simultaneous requests, each with the same "remember me" token. Only the first request will authenticate, because after Spring Security processes the first request, it changes the token. When Spring Security tries to process the next request, it throws a CookieTheftException.
That's the typical scenerio for the CookieTheftException when using PersistentTokenBasedRememberMeServices.
Here's a link that explains some things you can do about it: Grails Cookie Theft Exceptions
There's also an open issue with the Grails Spring Security Core plugin that discusses this problem: Remember me functionality fails intermittently with CookieTheftException: Invalid remember-me token
The JSESSIONID stuff is probably a red herring. If you're using PersistentTokenBasedRememberMeServices, your authentication won't need a session.
I'm using Spring Framework 3.0.5 and Spring Security 3.0.5 for developing a webapplication where users can log in and log out, using Remember-Me-Service, if they want to.
As I don't have pretty much experience, I wonder if it's working correctly. I use PersistentTokenApproach (with my own implementation, because I use Hibernate.) I can see the cookie is created on login and deleted on logout.
If I have an valid Remember-Me-Cookie and close the Browser, Im successfully logged in again when I open the browser again. So far, so good.
Now, I'd just like to know if those things I noticed are working as they are expected to or if I maybe did make a mistake.
1) When a user logs in without remember-me and the browser-tab is closed (not the browser itself), on reopening a new browser-tab he is still authenticated (he's using the same JSESSIONID). When closing the browser and reopening again, he isn't authenticated anymore. Regarding the security of a webapplication, is this a recommended ("normal") behaviour?
2) When remember-me used and the user is successfully authenticated (by login or later by cookie), there are no more checks on the cookie. that means, if meanwhile the user is online I'd delete the cookie from the database, the user would still be logged in, allowed to watch even the secured pages. I guess this happens because he was authenticated before and keeps using the same SESSIONID. When I close the browser and reopen it again, he isn't authenticated anymore.
3) When I dont own a cookie and open the main page, for every request I send (every picture, every file on the page) the server is checking for the rememberme-cookie. Is that correct?
Sorry for the newbie-questions, but I just want to make sure everything is working as it should. :-) Thanks in advance!
1) As far as tabs within a browser go, I am pretty sure they all share the same browser session. If you try using gmail or other web-based services you'll see the same behaviour when you close / open tabs. With older versions of IE (maybe version 6) separate instances had their own sessions, unless they were spawned from existing IE instances.
2) This sounds correct. Its not really ideal to hit the database on every request after they have been authenticated.
3) That is correct, as by default the spring security filters will be filtering on /* - and trying to look for authentication info. You can add excludes to your security config for resources you dont need to protect- ie
<http> <intercept-url pattern="/images/**" filters="none"/>