- there is only one Apache, and one Tomcat, on the same physical server
yes
- there are no Apache VirtualHosts (or there is only one), and there is
only one Tomcat <Host> section in server.xml
Apache virtualhost is there, and tomcat host is <Host name="localhost"...
- 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)
yes, authentication is mysql database
- there is only one single DNS domain (which simplifies certain issues)
yes like www.mywebsite.com
- all authentication is of type "Basic", which means based on the
exchange of HTTP headers from browser to server.
No, aaa is based on FORM authentication, and it should not be changed
The following is the aaa configuration in web.xml file
<login-config>
<auth-method>FORM</auth-method>
<realm-name>myWebSite Security</realm-name>
<form-login-config>
<form-login-page>/Login.jsp</form-login-page>
<form-error-page>/Login_fail.jsp</form-error-page>
</form-login-config>
</login-config>
<security-constraint>
<display-name>myWebSite Security</display-name>
<web-resource-collection>
<web-resource-name>myWebSite Security</web-resource-name>
<url-pattern>/aaa/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area -->
<role-name>myGroup1</role-name>
<role-name>myGroup2</role-name>
</auth-constraint>
</security-constraint>
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.
Hmm, I am sorry, if I mislead you. aaa is based on FORM authentication only
and my client doesnot want to chage it.
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.
Absolutely,
If I look into the request headers, when I log in to ccc using BASIC
authentication, it is storing the following information in request hearders.
authorization : Basic U3JpZGabkyuUZXN0aW5n
But, If I log into the aaa system (using form based authentication system),
it is not setting any such header. But still I can navigate to ccc, because
Tomcat manages this as SingleSignOnValve is enabled.
When I request to bbb pages, (Apache) as its not able to find any such
headers in browser cache, it is asking for credentials.. This is what
troubling me :-(
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.
Yes, I know :-) If I change it to BASIC it works.. But aaa application
should not be changed to BASIC. As per the client request, it should be FORM
authentication only :-(
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>
I find the following configuration in httpd.conf file.
AuthType Basic
AuthMySQLHost xx.xx.xx.xxx
AuthMySQLUser myUser
AuthMySQLPassword myPasssword
AuthMySQLDB myDataBase
and also found the following configuration in .htaccess file of each folder
in bbb application
AuthType Basic
require group myGroup1 myGroup2
AuthName "myWebSite Security"
Thanks,
Sridhar
awarnier wrote:
>
>
>
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17674656.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
