[ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-445: ------------------------------------- After doing some debugging, it appears that there may be a bug in Tomcat that is causing this. What's supposed to happen is that the overlord-idp context will set up a JSESSIONID cookie with the browser, so that each time the user goes back to that context she will get hooked up with the same session. This allows SSO because the container's form authentication will be bypassed due to the existence of authenticated user credentials in the session. Tomcat is correctly sending the Set-Cookie response header for the overlord-idp context. In addition, the browser is sending the proper Cookie request header when making requests to the overlord-idp context. For some reason, however, Tomcat is not using the session it told the client to utilize. So even though the session was created and the client sent the proper Cookie, Tomcat keeps responding with a new sessionid cookie. Note that this can easily be reproduced with only the overlord-idp.war deployed. Simply deploy that war and then hit this url: http://localhost:8080/overlord-idp/ This will prompt the user to log in and, if login was successful, it will display a simple JSP with several Overlord links. Simply refresh this page and you will be asked to log in again! At this point I don't know how to solve this issue and continue to use the PicketLink IDPFilter. I could instead revert back to using the PicketLink tomcat IDP valve. I am hesitant to do this because it means also reverting the installer to download and install JARs in tomcat/lib/ext. -- This message was sent by Atlassian JIRA (v6.2.6#6264)