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. S
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=bb&op=viewtopic&p=3879374#3879374
Reply to the post :
http://www.jboss.org/i
Looks like I figured out what was going on. There seems to be a bug in the
Tomcat implementation where it attaches the ClusteredSingleSignOn to the wrong
< Host >. I had:
< Engine name="jboss.web" defaultHost="A" >
...
< Host name="A" jvmRoute="node1" ... >
< Ali
anonymous wrote : Any clues as to why either of these scenarios are happening?
I just saw the clue: "session=null" A co-worker gave me the obvious suggestion
to try a simple JSP site to see if we can cluster that in the scenarios I just
outlined. Turns out JBoss works beautifully here, though
I'll jump back into this discussion.
I finally got the developers to get rid of their silly login servlet, and now
we're running with a proper FORM based authentication (setup via the web.xml)
using JAAS in JBoss.
I think I may have discovered the reason for why the login isn't being
clustered
Thanks Brian - that probably explains it.
If I don't front JBoss with Apache, do you know if JOSSO can provide single
sign-on capability across servers?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879299#3879299
Reply to the post :
http://www.jboss.org/i
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
Actually I am accessing it by IP address. Note that the host name in the
server.xml file is set to localhost on both servers.
Also I have tried a couple of other things I found reference to at
http://www.jboss.org/developers/projects/jboss/tc5-clustering.html- namely:
I nested
within of
Does the URL the user clicks on have a different server name?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879215#3879215
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879215
---
Brian - thanks for your reply.
In answer to your question - the redirect is not immediate. Following
authentication the browser is directed to a page containing a link to the
remote web app. Clicking on the link results in a pop-up to re-authenticate.
View the original post :
http://www.jboss.
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 replica
I am running into a similar problem trying to get clustered single sign-on to
work.
Keep in mind that I am new to JBoss so there may be something I am doing (or
not doing) which is very obviously wrong.
My setup is as follows:
- two JBoss 4.0.2 instances on different machines
- ClusteredSingleS
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 authenticatio
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 authenticati
Still getting my jargon down. The issue seems to be that the principal isn't
being replicated for the session using form based authentication. From other
posts, this would seem to indicate that it's not using ClusteredSingleSignOn.
However, I clearly see a log message:
2005-05-19 13:28:30,36
15 matches
Mail list logo