[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
I've thought about your problem more and realize my suggestion will not be reliable with the clustered version of SSO. As you've seen, there are two areas where ClusteredSingleSignOn maintains information about sessions associated with a sign-on. The first is the set of session id's maintained in the SSO's node in the TreeCache. This is used to provide global information to all nodes in the cluster about the complete set of sessions associated with the SSO. If a node removes the last entry from the set (due to session timeout), it invalidates the SSO. Really this set is just used for this purpose. The SSO node in the TreeCache only maintains session id's, not the sessions themselves because 1) the session id is all that's needed; the session is too heavy for the purpose and 2) session replication is a complex business, far beyond the scope of the SSO valve. Each node that has been accessed by a user also maintains a SingleSignOnEntry cached in the valve itself. This object maintains an array of sessions that have been accessed on that node. This array is used so the node can invalidate any sessions active on that node if a logout occurs. If other sessions exist on other nodes, it is the responsibility of those other nodes to invalidate those sessions. So, within the context of ClusteredSingleSignOn, on an individual node there is no place where all sessions associated with the SSO are guaranteed to be accessible. If all the apps that use SSO are distributable, then all the session data will be in the tree cache, but to access the sessions you would need to be able to find the Manager instance associated with each app. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=341#341 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=341 --- 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: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
drzewo wrote : I'll try to convince Remy (that might be tough though and might take some time, AFAIK Remy is off for vacation till August 16th) to enhance the SingleSignOn valve with optional logic, as a the described by me use case, I believe is a common scenario for those who use SSO. I'm curious about your use case (always like to know the different ways things are used). Typically when I've written webapps, if a user has not accessed the app for a while, I want their session to invalidate so I can free resources. Obviously I don't want the timeout of one session to affect others, but the SSO valve is designed to prevent that. I can imagine scenarios where keeping all sessions alive would be useful, but would be interested to know a real one. drzewo wrote : To be precise, to me, it would be much more appropriate and in the spirit of Remy's point of view if the logout action (session.invalidate() on one of the federeated sessions) removed an entry in the SSO cache only, leaving non-invalidated sessions untouched. Now, if another request arrived with the SSO id, the valve would do nothing as there's no such entry in the SSO cache, therefore user would heave to reauthenticate. Of course I might miss something. If the user accessed an app for which the session was not invalidated, they would not have to authenticate (and so you'd have single sign on but not single sign out). The Authenticator for each web app caches the credentials for the user in the session itself and uses them to reauthenticate users with valid sessions. The SSO valve caches credentials presented to one web app and makes them available to other webapps, but its support is not needed once the user has authenticated to an app. Best regards, View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=344#344 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=344 --- 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: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
My initial thought on this is that what you're suggesting seems like a reasonable option, but having read the tomcat-dev thread, I have to agree that doing this expands the scope of the SingleSignOn valve from handling authentication issues to managing session lifecycle, which is a pretty big change. (I consider invalidating associated sessions when one session in the SSO is invalidated for reasons other than timeout to be authentication related, although I can understand your point of view :) In any case, for maintainability reasons I want to keep the logic of ClusteredSingleSignOn the same as the Tomcat SingleSignOn valve on which it is based (except, of course, for communicating with the clustering layer). So, I wouldn't want to add this to ClusteredSingleSignOn unless the Tomcat folks were willing to add it to their version. (Besides Remy is the lead on JBoss/Tomcat integration, so I wouldn't add something he doesn't agree with). All that being said, I'm more than happy to help you get a custom version working. I suspect your problem is that your keepaliveSessions block is being executed too early. A session is not actually bound to the SingleSignOnEntry until the associate() method is called. This happens later in the pipeline, when the request gets to the authenticate() method of one of the Tomcat authenticators (e.g. org.apache.catalina.authenticator.BasicAuthenticator). If you move your keepaliveSessions block to ClusteredSingleSignOn.associate(), I believe this will fix your problem (haven't tried it myself). BTW, needing to move this block to associate() slightly increases my concern about adding this option. Now we're doing somethat that affects session lifecycle in an obscure location, rather than in a call from the invoke() method. Best regards, View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3888777#3888777 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3888777 --- 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: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
I think there was a problem with how TreeCacheSSOClusterManager was finding the JMX server -- I'm expecting your command line switch caused another JMX server to start and TreeCacheSSOClusterManager was finding that (sorry -- at work now and can't confirm). Last night I committed a patch to Branch_4_0 CVS that should fix this. Earlier today I replied to the e-mail you sent me with the config files. Email included a zip with the latest version and compiled classes, which if you want you can integrate to see if it solves your problem. Tonight I'll try using the -Dcom.sun.management.jmxremote switch and see if my patch resolves the problem. BTW, thanks for the very clear report. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887754#3887754 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887754 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
I was able to reproduce the problem by setting the -Dcom.sun.management.jmxremote parameter, and confirmed that the patch I committed last night fixes the problem (by finding the JMX server by calling MBeanServerLocator.locateJBoss() instead of just locate()). So, this issue is fixed in CVS. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887844#3887844 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887844 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
This is definitely quite odd if the same config works on one machine and not another. As you state, the log clearly shows the TreeCache being started and registered in JMX, yet TreeCacheSSOClusterManager cannot find it when it queries the JMX server. Couple things: 1) Can you go into the jmx-console and confirm the jboss.cache:service=TomcatClusteringCache MBean is indeed registered? 2) You noted that you get a message in the log for each SSO replication event. Can you confirm that the first one is logged at INFO level (the one you included in your report), followed by an ERROR level, followed thereafter by WARN levels. This is the expected behavior when it can't find the cache; if it's not what you're getting maybe that will give me a clue. 3) If the MBean is visible in the jmx-console, can you e-mail me your tc5-cluster-service.xml file and your server.xml file? Address is b_stansberry AT hotmail DOTcom View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887510#3887510 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887510 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
Thanks for reporting your results. I bought a new machine today and was about to start using it to try to reproduce your problem when I saw your post :) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3879374#3879374 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3879374 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
anonymous wrote : | If I don't front JBoss with Apache, do you know if JOSSO can provide single sign-on capability across servers? Looks like it. See: http://www.josso.org/configuring.html, the Domain-wide SSO Session Tokens section. I'll look into adding this feature to ClusteredSSO. Should be pretty straightforward. Kind of an obvious missing feature ;-) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3879375#3879375 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3879375 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
Do your webapps basically just issue a redirect to the other server as soon as authentication succeeds? That is, there is no delay, no going to another page or waiting for a user to click? If so, it might be because the ClusteredSingleSignOn is by default configured to use asynchronous replication. With an immediate redirect the browser request to the 2nd server might be getting there before the SSO replicates. If this immediate redirect is somehow important to your app, you can configure ClusteredSingleSignOn to use a non-default JBossCache. That cache should be configured to use REPL_SYNC instead of REPL_ASYNC. If immediate redirect is not important to your app but is just part of a test fixture, its probably easier to just find a way to add a delay (e.g. make user click a link to jump servers; add a pause before issuing redirect, etc.) See http://wiki.jboss.org/wiki/Wiki.jsp?page=SingleSignOn for more on how to configure ClusteredSSO to use a non-default JBossCache. If you need help, post back and I'll try to help more this evening when I'm off work. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3879208#3879208 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3879208 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
Does the URL the user clicks on have a different server name? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3879215#3879215 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3879215 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
ClusteredSSO uses a cookie to track a user, and the cookie is scoped to a host. So, it won't work for URLs with different hostnames. I need to add this point to the wiki page. When I'm manually testing ClusteredSSO I use a setup similar to what you describe, but I front it with Apache and mod_jk. I configure mod_jk to route requests for one app to one server and all requests for the other app to another server. The client sees everything as coming from one host. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3879252#3879252 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3879252 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
anonymous wrote : I'm having a possible related issue where a custom login servlet that we use to handle the Form authentication is doing something really bad, and not following any standards I'd assumed from your mention of j_security_check that you were using container managed authentication. ClusteredSingleSignOn is based on Tomcat's SingleSignOn valve, and is tightly integrated with Tomcat's Authenticators (which provide container managed authentication). Unless your login servlet is somehow integrated with the Tomcat infrastructure, ClusteredSingleSignOn won't work; you'd need to use TC's form authentication configured through web.xml. anonymous wrote : I'm going to try another possible approach. From what I can tell about mod_jk and Tomcat, the Tomcat server.xml Host element needs the jvmRoute=node name attribute to enable sticky sessions. Once we get that login servlet in a better state, I'll try enabling sticky sessions to see if this helps solve the notes replication issue. In my experience, sticky sessions are almost always the way to go for a web app that keeps any kind of server-side state. It should definitely prevent the 400 response from server B scenario I described (but maybe not whatever's causing your login servlet to issue a 400). If using sticky sessions is possible in your app, and using container managed authentication is an option, ClusteredSingleSignOn will work. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3878654#3878654 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3878654 --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn help
Here's what I believe is happening: Original request goes to server A. A's FormAuthenticator detects the need for a login, so it caches the request info in the session object and sends the login page. The request info is cached so the originally requested URL can be returned once authentication succeeds. This request info is cached in an internal data structure of the session object (the notes map), not in the attribute map that user code can manipulate using HttpSession.get/setAttribute(). I don't believe JBoss session replication replicates session notes, so the original request info is not replicated across the cluster. Login form submission goes to server B. B's FormAuthenticator authenticates you, but then checks your session for the note with the original request URL. It cannot find the note (wasn't replicated) so it issues a 400 error response. Normally it would issue a redirect response sending the browser back to the original request URL. anonymous wrote : If I force a refresh, then the request is redirected back to the original JBoss instance, and the authentication is correct. When you refresh, is the browser re-posting the login form, or is it resubmitting a GET for the original URL? I expect the former; if instead of refreshing you entered the original URL in the address bar and hit enter I expect you'd get the login page again. Would like to know for sure. The SSO context is not created until a user successfully authenticates, is redirected and the browser re-requests the original URL. So, I don't think a 2nd GET back to server A would succeed, since the successful login on B would not be communicated to A. anonymous wrote : I can't see any logging generated by single sign on, even with debug=2 and log4j.xml has org.jboss at debug level. Try turning on debug logging for org.apache.catalina. To get your use case to work, I think two things would need to be done: 1) Session replication would need to replicate objects in the notes map. 2) An SSO context would need to be created and replicated as soon as the login was done, not as part of the 1st request following authentication. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3878504#3878504 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3878504 --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security JAAS/JBoss] - Re: Tomcat SingleSignOn Invalid 403 Error
Someone sent me an email a couple days ago wanting to know if this problem has been resolved. My replies kept getting bounced by his mail server, so I'll reply here. Hope you see it. The SingleSignOn problem is fixed in JBoss 3.2.3. Tomcat versions beginning with 4.1.29 and 5.0.16 both include fixes for the issue, and JBoss 3.2.3 integrates those versions of Tomcat. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3835011#3835011 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3835011 --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
