[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Great. So the problem appears to be identified. Is there a jira tracking this issue? Do you know the anticipated release date of the next product cycle that this fix might be included in? Is there CVS or milestone access to this release so that I can test and give feedback in a more timely manner than in this past round? Thanks, Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3936691#3936691 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3936691 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
JIRA: http://jira.jboss.com/jira/browse/JBAS-3096 Scheduled for 4.0.5.CR1 (or 5.0.0.Beta if it comes out first. Release schedule: Neither of the above has a scheduled date right now. To monitor: http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10030subset=-1 Kind of a pain, but that's where you (and I) look. Access to code once the JIRA is fixed: http://www.jboss.com/wiki/Wiki.jsp?page=CVSRepository All alphas, betas, release candidates are available from the download page once released. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3936774#3936774 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3936774 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Brian, Thanks for your support and JBoss' continued commitment to enterprise quality middleware. anonymous wrote : | 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. | The thing here is that due to having a distributed session, I thought I had session information already stored on these nodes as a result being a member of the cluster. If this is true, I should have valid session information on node 2. There hasn't been an invalidate and the session on node 2 hasn't expired yet. So I have node 1's entire session replicated to node 2 at this point, but auth fails because we aren't willing to store username, password and the string representation of the authenticator in a cluster wide cache? Wouldn't hitting each node in effect transfer this information cluster wide anyway? I understand why the current implementation doesn't work. But don't see the drawbacks of changing the implementation to, in whatever way most convenient, make security information available to all interested nodes in push form. Pull just doesn't do it for me, especially when we're expressly trying to build a system tolerant of faults on the nodes you'd be pulling from. Thanks, Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3936318#3936318 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3936318 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
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=bbop=viewtopicp=3936023#3936023 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Hey Jim,
Finally got a chance to play with your wars, and things work as I expect -- but
not as you want :(
The issue is that the Principal does not get propagated around the cluster; the
username and password do. Two reasons for this:
1) Principal does not extend Serializable, thus you can't count on being able
to replicate it.
2) The security layer requires an authentication on each server -- replicating
around a Principal that is the result of an authentication on another server
won't cut it.
If when a failover occurs you request one of your wars w/ a login config, the
replicated username/password can be used to transparently authenticate you.
Thereafter you have a Principal on that server and all is well.
If you fail over to a war w/o a login config, there is no way to authenticate
you on the new server. Hence a 403.
If I uncomment the error page element in the hello/hello2 web.xml, and then do
a failover to one of those pages, I get redirected to main. I do not, however,
have to log in to main -- the sso valve is able to log in for me, since main
has a login config.
Perhaps you can create a custom authenticator for hello/hello2.
In 4.0.4.CR2 there is the ability to pretty easily add your own authenticators.
See jbossweb-tomcat55.sar's server.xml and META-INF/jboss-service.xml for
ideas on how to configure that (there is probably a wiki page too).
Get the org.apache.catalina.authenticator.NonLoginAuthenticator as a template
to create your own, and replace the authenticate method with this:
public boolean authenticate(Request request,
| Response response,
| LoginConfig config)
| throws IOException {
|
|// Have we already authenticated someone?
| Principal principal = request.getUserPrincipal();
| String ssoId = (String) request.getNote(Constants.REQ_SSOID_NOTE);
| if (principal != null) {
| if (log.isDebugEnabled())
| log.debug(Already authenticated ' +
| principal.getName() + ');
| // Associate the session with any existing SSO session
| if (ssoId != null)
| associate(ssoId, request.getSessionInternal(true));
| return (true);
| }
|
| // Is there an SSO session against which we can try to
reauthenticate?
| if (ssoId != null) {
| if (log.isDebugEnabled())
| log.debug(SSO Id + ssoId + set; attempting +
| reauthentication);
| // Try to reauthenticate using data cached by SSO.
| if (reauthenticateFromSSO(ssoId, request))
| return true;
| }
|
| // No principal + no SSO = reject!
| return false;
|
| }
Note I haven't tried that; just a suggestion :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3935706#3935706
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935706
---
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=lnkkid=110944bid=241720dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
It's late, the time when I dream up bad hacks. What if you add a FORM login config block to hello/hello2, but use your loginredirect.jsp as the login page? I would expect if the user hits hello w/o a login, loginredirect.jsp would get called, redirecting to main. However, in the failover case, the war now has a usable login config and since there is an SSO the Tomcat FormAuthenticator will use the SSO credentials and transparently log you in. Actually, I kinda like that; if it works I think it qualifies as a good hack :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3935708#3935708 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935708 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Assuming we start at node1 and then move to node2... 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. 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. Just thinking out loud. What are your thoughts? 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? -Jim PS: Still need to look into the NonLoginAuthenticator solution. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3935980#3935980 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935980 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Any news on 2314? -Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3935596#3935596 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935596 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Hi Brian, 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? -Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3932325#3932325 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3932325 --- 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=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
First, congrats to you; hope you had a great honeymoon :) I took another look this morning and saw the problem that eluded me before. See http://jira.jboss.com/jira/browse/JBAS-2314 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3898297#3898297 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3898297 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
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. Thanks, Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3898007#3898007 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3898007 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
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 Thanks, Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3893241#3893241 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3893241 --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
Jim, 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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3893254#3893254 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3893254 --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
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. -Jim View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3893285#3893285 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3893285 --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Clustered SSO not following the semantics of local SSO
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 :-) . View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3893288#3893288 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3893288 --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
