sridharmnj wrote:
Many thanks to all of you for responding to my problem.
I apologize, I hope I didnot mention my system architecture clearly. (As I
mentioned, it is an old application, which was developed 9 yrs ago, and no
documentation at all :-( )
I am accessing those applications like..
www.mywebsite.com/aaa -> (aaa webapp) Its based on Tomcat FORM based
authentication. (JDBC Realm)
www.mywebsite.com/bbb -> Here some static pages are deployed into Apache and
based on BASIC authentication.(mod_auth_mysql)
www.mywebsite.com/ccc -> (ccc webapp) Here dynamic pages are deployed on
Tomcat based on BASIC authentication.(JDBC Realm)
That makes it clearer, and provides some good news also.
What I guess from the above is :
- there is only one Apache, and one Tomcat, on the same physical server
- there are no Apache VirtualHosts (or there is only one), and there is
only one Tomcat <Host> section in server.xml
- the back-end for the authentication is the same MySql database system,
and the same table. In one case it is accessed by an Apache module
(mod_auth_mysql), in the other by some Java module under Tomcat (that's
my own weak point by the way, I'm not really a Java/Tomcat guy)
- there is only one single DNS domain (which simplifies certain issues)
- all authentication is of type "Basic", which means based on the
exchange of HTTP headers from browser to server.
But that last item troubles me. I believe that you mentioned initially
that the Tomcat authentication of www.mywebsite.com/aaa was "Basic",
even if it is form-based. That troubles me because, as far as I know,
that cannot be the case. There must be some other mechanism used there,
and that may be the very base of your problem.
My guess at this point is that the form-based authentication sets the
credentials in Tomcat, and keeps these alive in some form of Tomcat
"session" mechanism, but that it is never seen by the browser as a
"Basic authentication". In other words, the browser knows nothing about
it, and so can never pass this authentication from aaa to bbb.
If so, a very quick fix, would be to change the authentication setup of
your aaa webapp (in webapps/aaa/WEB-INF/web.xml), to make it the same as
in webapps ccc (webapps/aaa/WEB-INF/web.xml).
It's in the section at the end, in <security-constraints> or something.
The only visible difference in application aaa, would be that instead of
receiving the html login form, the user would see the same browser popup
than for application bbb and ccc.
You do not need to change the webapp application itself for this, just
the web.xml, and restart Tomcat, and maybe it will just magically start
working !! ??
Go on, try it, I'm curious !
If it works, then I will explain why.
But it would be consistent with the detailed explanation that you give
below, of the behaviour of the different applications.
If that does not work, then there are still a couple of details missing.
Can you then give us a copy of the relevant sections of the Apache
configuration (simplified/edited if you want), showing how exactly the
requests that initially all go through Apache (I suppose from the
above), get passed to Tomcat if needed ? There should be things like this :
<Location /aaa>
JkMount /aaa ajp13
JkMount /aaa/* ajp13
...
</Location>
<Location /bbb>
AuthType Basic
Require valid-user
...
</Location>
(or, maybe, it is not JkMount and it is some other Apache-Tomcat
connector ?)
André
All the above applications are using same usertable for credentials.
Scenario 1: When I logs into the bbb, (Apache-BASIC) it is poping up a
dialog box with username and password and after providing the details it is
authenticating using mod_auth_mysql. I have a link to the ccc (Tomcat-BASIC)
from bbb pages. When I clicked that link, I am able to navigate those pages
without providing the credentials again. (I hope, here tomcat is finding
auth headers which are set by Apache)
Scenario 2: When I directly logs into ccc (Tomcat-BASIC) it is poping up a
dialog box with username and password and after providing the details, it is
authenticating using Tomcat BASIC authentication. If I click a link to bbb,
I am able to navigate to it without providing the details 2nd time. (I hope,
here Apache is finding the credentials which are set by Tomcat).
Scenario 3: When I logs into aaa, (TOMCAT-FORM) after authentication, I am
able to access ccc (TOMCAT-BASIC) without providing the credentials again.
(I hope, here Tomcat is sharing the credentials between FORM and BASIC
authentication credentials, as SingleSignOnValve is enabled).
These Scenarios 1,2,3 are working perfectly, and I need those as is.
Scenario 4: When I logs into aaa, (Tomcat-Form) after authentication, If I
click a link to bbb (Apache-BASIC) again its poping up a window for username
and password.
This is (Scenario 4) what I need to change. When a user logs into aaa using
Tomcat-Form based authentication and clicks a link to bbb, he should be
directly allowed to it without asking the credentials 2nd time.
Is there any way to do it, without modifying the Apache Authencitation?
I am really sorry if I am confusing you. Please let me know still if you
need any other details.
Thanks,
Sridhar
Pid-2 wrote:
Johnny Kewl wrote:
----- Original Message ----- From: "Propes, Barry L "
<[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Hi,
I am integrating two websites using single sign on. I have two sites
namely
aaa.com and bbb.com.
I enabled SingleSignOn valve in server.xml file, and trying to access
Its not going to work...
Its not because of TC, its because of the way cookies are handled by the
browser.
Its been a long long time since I wrote a filter to do this, and there
are probably better third party products out there.
But this is what I remember...
The SingleSignOn is addressing the issue of sign on across web apps and
within a single TC... not across machines.
ie Tomcat has to at least be able to track the session. If thats covered
then...
Then and I forget the terminology.
A browser will consider this the same domain....
aaa.com/webapp/servlet1
aaa.com/webapp/servlet2
and I think even
aaa.com/webapp2/servlet1
but as soon as that becomes bbb.com
the "browser" treats it like a stranger and does not return the session
key, nor auth info for the other domain... so TC/Apache is screwed
because the browser doesnt want to play.
Vaguely I remember setting "persistent" cookies in the browser, and then
tracking my own cookies across machines... but it also meant a complete
redo of all the security and TC's generic security could not be used.
I remember seeing thrid party tools... but if you cant change the one
webapp, you into something really creative, creating a filter wont work
because security happens before the filter.... you have a creative
problem on your hands ;)
E.g. OpenID, JOSSO etc
Search google for "Java Single Sign On".
As has been stated, SingleSignOnValve isn't a true SSO solution.
p
I think if you can put TC behind Apache, thus getting it back to the
same domain name, and the distinguishing only on sub context...
ie
aaa.com/images/in apache
aaa.com/webapp/someservlet and the call is passed thru to TC
Then the browser will like it and return the authentication details....
otherwise is going to be some kind of complex proxy type thing to trick
the browser.
Good luck...
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
