tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Single sign on issue with Tomcat and Apache
Date Thu, 05 Jun 2008 15:51:09 GMT

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..
> -> (aaa webapp) Its based on Tomcat FORM based
> authentication. (JDBC Realm)
> -> Here some static pages are deployed into Apache and
> based on BASIC authentication.(mod_auth_mysql)
> -> (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 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 /bbb>
   AuthType Basic
   Require valid-user
(or, maybe, it is not JkMount and it is some other Apache-Tomcat 
connector ?)


> 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 " 
>>> <>
>>> To: "Tomcat Users List" <>
>>>> Hi,
>>>> I am integrating two websites using single sign on. I have two sites 
>>>> namely
>>>> and
>>>> 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....
>>> and I think even
>>> but as soon as that becomes
>>> 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
>>> apache
>>> 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 :
>>> The most powerful application server on earth.
>>> The only real POJO Application Server.
>>> See it in Action :
>>> ---------------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail:
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail:
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message