tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sridharmnj <sridhar...@yahoo.co.in>
Subject Re: Single sign on issue with Tomcat and Apache
Date Thu, 05 Jun 2008 19:27:20 GMT

If there is no way to do this, what changes do you suggest?

except aaa changes.

Is it a better idea to move apache pages (bbb) into the tomcat (ccc)? (so
that there will be only tomcat authentication exists)

Thanks,
Sridhar

awarnier wrote:
> 
> Well, Johnny, we seem to agree..
> 
> Johnny Kewl wrote:
>> 
>> ----- Original Message ----- From: "sridharmnj" <sridharmnj@yahoo.co.in>
>> To: <users@tomcat.apache.org>
>> Sent: Thursday, June 05, 2008 4:33 PM
>> Subject: Re: Single sign on issue with Tomcat and Apache
>> 
>> 
>>>
>>> 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)
>>>
>>> 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.
>> 
>> sridharmnj
>> Ok this is very different to what we first thought.
>> This is a guess...
>> 
>> I think the problem is that you mixing auth methods...
>> You have to make them all BASIC in this case.
>> The browser is on the same domain... so I think it will be returning the 
>> auth header info, can check with a dump valve or get wireshark and just 
>> make sure it is returning header info... but I think it is, the problem 
>> is that the auth info is not the same.
>> 
>> I've never used FORM authentication, but I guess it just reads the UID 
>> and Password fields and then TC starts tracking that cookie as 
>> authenticated.
>> BASIC does not do that... there the browser returns a Base64 encoded 
>> mash and that is interpreted.
>> 
>> So if you go to say ccc (BASIC) and then bbb (BASIC)..... you havnt 
>> said... but I think that will work.
>> But when you go to FORM.... all the browser sends Apache is a little old 
>> cookie... and the BASIC logic will go "what the hell"... and challenges 
>> the browser.
>> 
>> So the initial thought that it was a domain problem is not correct... 
>> you just mixing incompatible auth schemes.
>> I think you have to lose the FORM auth... and even though you cant 
>> change the web app, I think that is is possible externally... all thats 
>> going to happen is that the browser pops up a password box... and that 
>> auth FORM is now going to be redundant.
>> 
>> I think the FORM auth has to go, must be made BASIC... my guess.
>> 
>> ---------------------------------------------------------------------------
>> 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17677750.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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message