This is what the sso process does. When a login request is sent. The first response back to the browser is a redirect to the context root. This doesn't have the token cookie in the response. The web application has a welcome page which forwards internally. I put a breakpoint in SSOTokenManager inside the if(!ssoCookieFound) { condition. It got hit twice immediately. The second request was for a css file in the page that was being streamed back. (Note the browser had not yet displayed the resulting page.) Looks like IE starts processing as soon as it gets any content. Now we have 2 requests in there to generate the token. The TokenManager now calls JBOSSSingleSignOn to generate the token (getTokenSecret method.) The federation server now ends up with 2 requests for the same principal id. It generates one token and returns it for one request. The second request comes in and it generates a second token replacing the eariler one. However now the browser has the earlier token with it. So when you connect to a different app the federation server doesn't find the token since its hashmap now has the new value. Looking at the code, I was thinking that maybe we should synchronize the generateSecret method in org.jboss.security.federation.service.Trust and make it return an existing secret value if it find one. Only if it doesn't find one then generate a new one. That's my 2 cents worth. Hope this helps Roshan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023275#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...