tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Single sign on issue with Tomcat and Apache
Date Thu, 05 Jun 2008 16:42:03 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)
> 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?

Not to my knowledge.  AFAIK Tomcat sets a user principal that is not 
visible to the HTTPD server's authentication/authorization module.

HTTPD's authenticated remote user header can be visible downwards to the 
container with the right configuration, and the two Tomcat webapps can 
co-operate, but I don't believe that there is anything in JK to allow it 
to propagate a principal upwards.

Maybe one of the mod_jk committers has better info.


> 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