Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 82795 invoked from network); 5 Jun 2008 19:28:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jun 2008 19:28:06 -0000 Received: (qmail 46983 invoked by uid 500); 5 Jun 2008 19:27:56 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 46956 invoked by uid 500); 5 Jun 2008 19:27:56 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 46945 invoked by uid 99); 5 Jun 2008 19:27:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jun 2008 12:27:56 -0700 X-ASF-Spam-Status: No, hits=4.5 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jun 2008 19:27:05 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1K4L7I-0000Fq-LA for users@tomcat.apache.org; Thu, 05 Jun 2008 12:27:20 -0700 Message-ID: <17677750.post@talk.nabble.com> Date: Thu, 5 Jun 2008 12:27:20 -0700 (PDT) From: sridharmnj To: users@tomcat.apache.org Subject: Re: Single sign on issue with Tomcat and Apache In-Reply-To: <484834F6.8000004@ice-sa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: sridharmnj@yahoo.co.in References: <17633391.post@talk.nabble.com> <3A55348B50FD2A40AAA40ABA16C6B6D60E7CDA88@EXNJMB23.nam.nsroot.net> <025501c8c66e$2a6ba8e0$0300000a@animal> <48478F67.4040509@pidster.com> <17671253.post@talk.nabble.com> <010301c8c727$8bda7160$0300000a@animal> <484834F6.8000004@ice-sa.com> X-Virus-Checked: Checked by ClamAV on apache.org 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" >> To: >> 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