Thanks! You found a bug in the distributed session manager that I'm fixing for 4.0.4.GA. http://jira.jboss.com/jira/browse/JBAS-3085
anonymous wrote : | This hack works, but only if node1 stays active. In the scenario where sticky sessions are used and node1 crashes, traffic is sent to node2, however node2 still lacks the authentication context and forces a login. If someone where in a hello workflow, they'd be kicked back out to main. Getting better, but unfortunately not the transparent fail over our hello users are expecting. Can you change the test wars so to remove the "distributable" element from web.xml? After that you should see this behavior: 1) Start on node1. Kill node1 (not a shutdown -- a kill -9 or End Process Tree from Windows TaskManager). Should work as you want. 2) Start on node1. Stop the node1 worker in Apache. Use the browser to fail over to node2. Should work OK. Then do a clean shutdown of node1. Should still work OK. (If the webapp is marked "distributable", won't work OK anymore -- this is the bug I fixed; it will work OK in 4.0.4.GA). 3) Start on node1. Do a clean shutdown of node1. Use browser to fail over to node2. You'll have to log in. I'll explain more about this below. anonymous wrote : | It feels to me that in order to support true enterprise authentication (along with the already good clustered session support) a clustered aware authentication service would need to be developed. That while a Principal may not be able to be replicated, the underlying credentials in their various forms can. You also know when users authenticate and log off. It seems to me that this service could use these authentication events along with the underlying credential data to synchronously recreate a Principal on each node upon login, and clean up upon logoff. I suppose this creation could be deferred as long as you're willing to store the credential info and original authenticator mapping forever. What you described (with the deferred creation) is basically how ClusteredSSO works. The limitation it has is that it is tightly integrated with the Tomcat authentication layer -- the deferred creation is done by a Tomcat authenticator. It won't work if a webapp doesn't have an authenticator, which is what you were trying to do. The reason #3 above doesn't work is we're not willing to store the credential info forever. We discard the info 1) if invalidate() is called on any session associated with the SSO (aka logout) or 2) if all sessions associated with the SSO across the cluster are expired. Sessions are expired either due to timeout or undeployment of their associated webapp. In scenario #3, the only sessions associated with the webapp are on node1 (since you haven't accessed node2 yet -- once you do you have a session on node2). The sessions are all expired during shutdown of node1, so the SSO is invalidated. I'm thinking about ways to solve #3 w/o leaking memory across the distributed system. Haven't solved it yet; what I have now is as far as it will go for 4.0.4. The workaround to the problem is to use the #2 approach -- stop accepting requests for the server about to be shut down, and then after a while shutdown the server. That's a better approach in general anyway. anonymous wrote : Also what is JBoss' view of Clustered SSO/Enterprise SSO? This feature as I understand the concept seems broken to me. Regardless of our discussions and any eventual work around, is there commitment within the organization to fix this problem? Or is this particular situation not in line with current JBoss goals for Clustered/Enterprise SSO? First, JBoss is definitely interested in making the existing ClusteredSSO feature as good as it can be. I really want to thank you Jim for pushing your use case -- working with it I've now found 2 issues that limit its usefulness. That said, the current ClusteredSSO is a fairly limited feature. It will never, for example, move away from the tight coupling to the Tomcat authenticators. It is not intended to be JBoss' final answer to enterprise SSO -- there is also work underway on SSO solutions with broader applicability. Best to monitor the security forums to follow events. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3936023#3936023 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3936023 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
