The behavior should be the same on one machine or across a cluster. If the SSO succeeds on one app on a cluster node, it should succeed on all. The SSO is driven by a cookie that applies to all apps with the same hostname.
1) If you can provide a testcase with a couple war's showing this, that would be ideal. The key thing is something that duplicates your logic for having various apps rely on a main app for authentication. I suspect the problem could be related to this.
2) You can try adding the following attribute to the element for ClusteredSingleSignOn in server.xml
That one's a shot in the dark; if it works let me know.
3) How exactly does it fail:
a) You're on node 1. You fail over to the "main" app on node 2. All is well. Then you click over to another app on node 2. SSO fails -- need to authenticate.
b) You're on node 1. You fail over to another app on node 2 (not the main app). SSO fails -- need to authenticate.
requireReauthentication="true" causes things to break even before fail over. :)
And to answer question 3, both apply. It seems that SSO login context only gets shared across the cluster in the webapp that originated the login. However, that webapp doesn't have any trouble regardless of where you start.
I'll try to come up with a cut down. Where do you want the wars?
Also, since I don't have a login form registered for the other SSO apps, I get the following error.
HTTP Status 403 - Configuration error: Cannot perform access control without an authenticated principal
Locally I have the 403 error page redirect to the main login page. A main log-out invalidates the local SSO. So SSO log-out seems to work like log-in except in reverse. This is nice (at least for my app). I simply don't supply the other webapps with login pages and when their auth fails I send them over to the main login.
Locally everything works great. Clustered I automatically get logged into main, but nothing else. Since main houses my SSO login form, there's now no way to log in the other apps after a failover.
I also have my cutdown, let me know where you'd like the files. 3 files around 350K each.
The files are on their way.
Thanks. Got them.
I should probably have included better steps to reproduce in my E-mail. Here they are.
Load main, hello, hello2 in a cluster. Hit main, and log in via login form. You can then travel between all three apps via their navigation links. Find out which server you are on by looking at the server.log. Kill that server. Trying to reload either hello or hello2 will fail. Main works uneffected.
This seems to hold true no matter the navigation after failover. Logging out of main, and then back in, unlocks hello and hello2 normally.
If you need anything further, feel free to ask.
Any verification of this? Another person within my organization has been able to reproduce the problem. It'll be important for us to know:
A) That this is a bug
B) What the timeframe for resolution will be
Sorry for the slow response. If this is important for your organization and you need someone from JBoss to help get answers on this quickly, you should contact our support group. Please understand the forums are a form of free support and don't necessarily get the attention we would like to give them due to time constraints with dealing with support calls in addition to performing our actual development duties. :-)
That being said, there is a fundamental difference between SSO on a single node and over a cluster. On a single node, if the "requireReauthentication" attribute has been set to false (the default), once a user has been authenticated their Principal object is cached and for future requests is directly bound to the request object without making an authentication call to the JBossSecurityManagerRealm. However, the Principal is not replicated over the network, (because, among other reasons, Principal does not implement Serializable). So, the first time a user switches to another node, the Principal object is not cached and the ClusteredSSO valve has to authenticate the user using the login credentials (username, password) that have been cached. This should happen transparently to the user, as the required credentials are replicated.
In your described use case, only the main war has authentication enabled; if the first request to a new node is for one of the other wars, the ClusteredSSO valve will not be able to authenticate the user, and the request will fall through to your loginredirect.jsp.
I haven't had a chance yet to play with your wars, but I'm quite certain the problem you're seeing is related to the above.
Thanks for the response Brian. I know you're under time pressures.
What you say makes sense. What it feels like JBoss is doing in SSO is that upon authentication with one app the principal gets propagated to the other webapp's context and the credentials are cached. Or there is some security context pointer back to the original login app (for single log-out). On fail over the cached credentials are used, but that initial push propagation doesn't happen.
At least that's what it feels like as a user. Cached credentials would explain why main functions correctly. I get the feeling that the SSO credentials aren't passed to the other webapps in SSO and that something else happens behind the scenes that allows the other apps to authenticate their principal. Not caching the credentials in all the apps and not pushing out the SSO principal again on failover would explain what I'm seeing.
I respect that this is free support. Pretty good free support at that. My organization is currently investigating the viability of JBoss. Once we're confident that JBoss will fit the bill we'll have no problem paying JBoss for support. Until then I know it's a bit of a catch-22. I'm willing to dedicate as much time as I need to to get you what you need. Let me know if there is anything.
I should be able to run through your test wars in the next day to get an exact idea of what's going on.
I definitely appreciate your good inputs on this. Getting a test case so quickly is not the norm with most forum questions :-) .
Any luck verifying this defect? I've been away on my honeymoon these past couple weeks. Let me know if you need any anything else.
Finally had the chance to circle back and re-ramp on my clustered project. This problem is still there. Session information seems to be replicated fine, but not auth context.
I didn't exactly understand your explanation above. Is auth context not pushed along with session information out to all nodes upon login?