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
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
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
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
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.
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
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 :
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.
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
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
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
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
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
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
14 matches
Mail list logo
