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.
>From the looks of it it seems as if the app server is streaming content back
>to the browser immediately.
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#4023275
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023275
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
