RE: Single sign on
> From: Linux Support [mailto:ossuppor...@gmail.com] > Subject: Single sign on > Using 8.5.5 on solaris. Can you please point me in the direction of some > documentation/link/blog for how to set up the SSO for a application > deployed. Start here. http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Single_Sign_On_Valve If you want to utilize an existing authentication/authorization system, look through this to see if there's a Realm you can use: http://tomcat.apache.org/tomcat-8.5-doc/realm-howto.html http://tomcat.apache.org/tomcat-8.5-doc/config/jaspic.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single Sign On Replication with New Tomcat Cluster Nodes
Great, thanks for taking a look. I've submitted a bug report for replicating the SingleSignOnEntry cache data here: https://issues.apache.org/bugzilla/show_bug.cgi?id=57338 On Tue, Dec 9, 2014 at 9:23 PM, Keiichi Fujino kfuj...@apache.org wrote: I examined the code of ClusterSingleSignOn. This behavior seems to be bug. There seems to be some other problems. a) When a new node is started, SingleSignOnEntry of cache is not replicated. (you mentioned.) b) ClusterSingleSignOn does not implement ClusterValve. c) Unsupported to BackupManager. d) There are no documents. In order to resolve this problem(a), it must be synchronized between cluster nodes cache of SingleSignOnEntry at startup. Please open a bug entry for a). 2014-12-05 3:35 GMT+09:00 Aaron R aaron14.pub...@gmail.com: Hello, I have a Tomcat cluster (7.0.42) that is configured to use the DeltaManager for session replication. It also uses the ClusterSingleSignOn valve for SSO and for propagating authentication to the other nodes in the cluster. If I log into Tomcat1, the session state and the single sign on state are successfully replicated to Tomcat2, so that when Tomcat1 goes down, the load balancer switches me to Tomcat2, and I am still authenticated and am able to access other applications on the server. The problem I'm having is that if a new node (Tomcat3) is then brought up after I have logged in, that new node does not appear to get any SSO state replicated to it, as I get a 403 error when trying to access a different application on the server. The regular session state is correctly replicated to it, but I don't seem to have SSO authentication on this new server. Should this scenario work? Is it possible to get the single sign on state propagated to nodes that come online after the user has logged in? I see one instance of someone mentioning a similar issue in passing a while back ( http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%3C15060d5e0809211745s522af93bv153367d9183c6e5e%40mail.gmail.com%3E ), but I didn't see any followup after that. Thanks, Aaron -- Keiichi.Fujino
Re: Single Sign On Replication with New Tomcat Cluster Nodes
I examined the code of ClusterSingleSignOn. This behavior seems to be bug. There seems to be some other problems. a) When a new node is started, SingleSignOnEntry of cache is not replicated. (you mentioned.) b) ClusterSingleSignOn does not implement ClusterValve. c) Unsupported to BackupManager. d) There are no documents. In order to resolve this problem(a), it must be synchronized between cluster nodes cache of SingleSignOnEntry at startup. Please open a bug entry for a). 2014-12-05 3:35 GMT+09:00 Aaron R aaron14.pub...@gmail.com: Hello, I have a Tomcat cluster (7.0.42) that is configured to use the DeltaManager for session replication. It also uses the ClusterSingleSignOn valve for SSO and for propagating authentication to the other nodes in the cluster. If I log into Tomcat1, the session state and the single sign on state are successfully replicated to Tomcat2, so that when Tomcat1 goes down, the load balancer switches me to Tomcat2, and I am still authenticated and am able to access other applications on the server. The problem I'm having is that if a new node (Tomcat3) is then brought up after I have logged in, that new node does not appear to get any SSO state replicated to it, as I get a 403 error when trying to access a different application on the server. The regular session state is correctly replicated to it, but I don't seem to have SSO authentication on this new server. Should this scenario work? Is it possible to get the single sign on state propagated to nodes that come online after the user has logged in? I see one instance of someone mentioning a similar issue in passing a while back ( http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%3C15060d5e0809211745s522af93bv153367d9183c6e5e%40mail.gmail.com%3E ), but I didn't see any followup after that. Thanks, Aaron -- Keiichi.Fujino
Re: Single Sign-On problems
Carlton Whitmore wrote: Andre, The only reason I think it's Tomcat because when we change the Tomcat version it seems to affect the speed of the application (Tomcat 7 runs very slow, but no SSO errors; Tomcat 6 runs fast, but SSO errors). We're using Active Directory to authenticate. I guess it could be SSL as well. I've change the domain controller, but that didn't affect the issue. Here is the code we changed in the conf\web.xml file: welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file /welcome-file-list filter filter-nameNtlmHttpFilter/filter-name filter-classjcifs.http.NtlmHttpFilter/filter-class init-param param-namejcifs.http.domainController/param-name param-value192.168.100.6/param-value /init-param init-param param-namejcifs.smb.client.domain/param-name param-valueadvocacyinc/param-value /init-param init-param param-namejcifs.smb.client.username/param-name param-valueSQL_LegalFiles/param-value /init-param init-param param-namejcifs.smb.client.password/param-name param-valuepassword/param-value /init-param init-param param-namejcifs.smb.lmCompatibility/param-name param-value3/param-value /init-param !-- ** needs reviewed to avoid domain Preauth check init-param param-namejcifs.smb.client.ssnLimit/param-name param-value1/param-value /init-param -- /filter filter-mapping filter-nameNtlmHttpFilter/filter-name url-pattern/*/url-pattern /filter-mapping 1) you do know that this NtlmHttpFilter is no longer developed or supported, and that it will never support NTLM v2 (as is standard with Windows Vista, 7 and later), right ? You should be thinking about switching to Jespa or Waffle. 2) anyway, the jCIFS filter can do quite extensive logs of what it does (see jcifs.util.loglevel). You could try using that and check what it is telling you about the failures. 3) when you mention SSO failures, what do you mean exactly ? the browser popping up a builtin authentication dialog ? or something else ? And is the above your standard operational configuration, or a simplified one you are just using for this test ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Single Sign-On problems
Pid, I can't seem to open any of your emails. Outlook (with Entrust) says that they are encrypted but with invalid mime. From: Pid [mailto:p...@pidster.com] Sent: Monday, August 16, 2010 12:54 PM To: Tomcat Users List Subject: Re: Single Sign-On problems
Re: Single Sign-On problems (SSO not the cause)
Carlton Whitmore wrote: I just verified that the issue is not with SSO. I tested this by accessing the URL until I got Page cannot be displayed then I tried accessing https://myserver.advocacyinc.org:8443 and got the same thing. We're not doing any redirects from IIS. Could JCifs be tying up the system? Any ideas? With respect, I think that you are getting quite a few things mixed up. There are threee different things altogether : - User Authentication, here achieved (or not) at the Tomcat level by the jCIFS NtlmHttp filter. - SSO, meaning Single-Sign-On, which means that the user needs to authenticate to the application (or system) only once, and can subsequently call one or more applications without having to login again. Here, SSO is achieved indirectly by the jCIFS authentication, but that is only because this kind of authentication is implicitly carried over to the entire browser/server connection. - and then there is SSL, which is implicated when you use the HTTPS protocol (which is really a HTTP conversation, but carried over an encrypted SSL link). That implies that the data circulating between the browser and the server (and vice-versa) is encrypted. But in this case it has nothing to do with Authentication or SSO. The 3 above things do exist in your case, but they do not really have much to do with one another. And what you tried above does not prove anything. Considering what you have told us so far, I believe that IIS has nothing to do with the problem, and neither does SSL/HTTPS. I believe that your problem is at the jCIFS/NTLM Authentication level, but at this point this is more a hunch than a certainty. To your question Could JCifs be tying up the system?, my answer would be yes, it could, very easily. And the entire thing seems quite off-topic for this Tomcat users list (because the problem does not seem at this point to be linked to any Tomcat code, but more to the authentication side, which is code coming from somwhere else). Unfortunately, I don't really know where to send you, because the jCIFS HTTP filter is no longer developed nor supported, and has not been for quite a few years. I believe that the people which you should first contact on this are the vendor of your application, since after all your setup is their recommendation. Maybe you should point out to them that they are recommending a solution which is by now outdated and no longer technically working; and ask them for an alternative recommendation. Additional info : Jespa (see www.ioplex.com) is the closest relative to the jCIFS filter. It is also a servlet filter, which works (from the Tomcat point of view) much like the jCIFS filter. You can download and test it for free. But setting it up is not necessarily easy if you do not have some background knowledge of how NTLM authentication works in the first place. I not tried Waffle myself. But Melinda who has, seems to have gotten her system to work with it in .. a short time, after spending many hours trying to do NTLM authentication in other ways. From what I checked just now at waffle.codeplex.com, they even propose a servlet filter, which should make it all the easier for you to replace jCIFS. From what I know (first-hand for Jespa, hearsay for Waffle) both will work will all versions of NTLM and all kinds of Windows workstations (including XP, Vista and W7). Otherwise, try what I mentioned before : increase the log level of the jCIFS filter, and look in its logfile what it has to say about the failed authentications. But this exercise may turn out to be quite pointless, as you should no longer be using this filter anyway. Even if you fix your current issue, new ones are bound to appear as your workstations or servers get updated. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single Sign-On problems
Carlton Whitmore wrote: We're running Windows 2008 R2, Tomcat 6, MS SQL 2005, JDK 6 update 20 and authenticating using AD from Windows 2003 R2 server. The application we're using causes intermittent single sign-on errrors. We tried to upgrade to Tomcat 7 and the SSO errors went away, but the system was so slow it was unusable. Sometimes we get 8 SSO errors before we're able to use the system, but when it works it's very fast. Would you mind specifying which SSO mechanism you are using where, and why you believe that the problem is related to Tomcat ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single Sign-On problems
On 15/08/2010 17:45, André Warnier wrote: Carlton Whitmore wrote: We're running Windows 2008 R2, Tomcat 6, MS SQL 2005, JDK 6 update 20 and authenticating using AD from Windows 2003 R2 server. The application we're using causes intermittent single sign-on errrors. We tried to upgrade to Tomcat 7 and the SSO errors went away, but the system was so slow it was unusable. Sometimes we get 8 SSO errors before we're able to use the system, but when it works it's very fast. Would you mind specifying which SSO mechanism you are using where, and why you believe that the problem is related to Tomcat ? ... and how it can be fast and slow at the same time. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
RE: Single Sign-On problems
Andre, The only reason I think it's Tomcat because when we change the Tomcat version it seems to affect the speed of the application (Tomcat 7 runs very slow, but no SSO errors; Tomcat 6 runs fast, but SSO errors). We're using Active Directory to authenticate. I guess it could be SSL as well. I've change the domain controller, but that didn't affect the issue. Here is the code we changed in the conf\web.xml file: welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file /welcome-file-list filter filter-nameNtlmHttpFilter/filter-name filter-classjcifs.http.NtlmHttpFilter/filter-class init-param param-namejcifs.http.domainController/param-name param-value192.168.100.6/param-value /init-param init-param param-namejcifs.smb.client.domain/param-name param-valueadvocacyinc/param-value /init-param init-param param-namejcifs.smb.client.username/param-name param-valueSQL_LegalFiles/param-value /init-param init-param param-namejcifs.smb.client.password/param-name param-valuepassword/param-value /init-param init-param param-namejcifs.smb.lmCompatibility/param-name param-value3/param-value /init-param !-- ** needs reviewed to avoid domain Preauth check init-param param-namejcifs.smb.client.ssnLimit/param-name param-value1/param-value /init-param -- /filter filter-mapping filter-nameNtlmHttpFilter/filter-name url-pattern/*/url-pattern /filter-mapping Carlton Whitmore Systems Analyst Advocacy, Inc. http://www.advocacyinc.org https://exchange2003.advocacyinc.org/exchweb/bin/redir.asp?URL=http://www.advocacyinc.org/ From: André Warnier [mailto:a...@ice-sa.com] Sent: Sun 8/15/2010 11:45 AM To: Tomcat Users List Subject: Re: Single Sign-On problems Carlton Whitmore wrote: We're running Windows 2008 R2, Tomcat 6, MS SQL 2005, JDK 6 update 20 and authenticating using AD from Windows 2003 R2 server. The application we're using causes intermittent single sign-on errrors. We tried to upgrade to Tomcat 7 and the SSO errors went away, but the system was so slow it was unusable. Sometimes we get 8 SSO errors before we're able to use the system, but when it works it's very fast. Would you mind specifying which SSO mechanism you are using where, and why you believe that the problem is related to Tomcat ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Single Sign-On problems
From: Carlton Whitmore [mailto:cwhitm...@advocacyinc.org] Subject: RE: Single Sign-On problems Tomcat 7 runs very slow, but no SSO errors; Tomcat 6 runs fast, but SSO errors Have you looked to see what's going on during the slowdown? Is there high CPU usage, or perhaps swapping? Is there a possibility that under Tomcat 7, DNS lookups are occurring (reverse or normal) that weren't going on with Tomcat 6? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Single Sign-On problems
Charles, The server is running as a VM on Hyper-V R2. I've checked the CPU and disk access during these times and everything looks fine. We're using internal DNS servers so I don't think lookup resoltuion is an issue. Carlton Whitmore Systems Analyst Advocacy, Inc. http://www.advocacyinc.org http://www.advocacyinc.org/ Advocacy, Inc. is a non-profit agency advocating for, protect and advance the legal, human and service rights of people with disabilities. If you would like to help our cause please choose the donate link on our website. From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Sun 8/15/2010 9:07 PM To: Tomcat Users List Subject: RE: Single Sign-On problems From: Carlton Whitmore [mailto:cwhitm...@advocacyinc.org] Subject: RE: Single Sign-On problems Tomcat 7 runs very slow, but no SSO errors; Tomcat 6 runs fast, but SSO errors Have you looked to see what's going on during the slowdown? Is there high CPU usage, or perhaps swapping? Is there a possibility that under Tomcat 7, DNS lookups are occurring (reverse or normal) that weren't going on with Tomcat 6? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Single Sign-On problems
From: Carlton Whitmore [mailto:cwhitm...@advocacyinc.org] Subject: RE: Single Sign-On problems The server is running as a VM on Hyper-V R2. I've checked the CPU and disk access during these times and everything looks fine. We're using internal DNS servers so I don't think lookup resoltuion is an issue. What's the guest OS? If it's Linux (probably not, if you're using Hyper V), then you might see delays while /dev/random gathers entropy. Time to take some thread dumps and see what's going on. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single Sign-On in two server
Have a look at CAS http://www.jasig.org/cas On Wed, Jun 16, 2010 at 8:17 PM, Chandana Napagoda cnapag...@gmail.com wrote: Hi, I have two tomcat instance, frist one run on https://localhost:8080 and secound one run on https://localhost:9090. each server i have deployed Admin and User web application I need to implement Single Sign-On for this two web application. While user is logging to https://localhost:8080/admin;, That user able access https://localhost:9090/user; application I need to login that user without promoting login screen. is it possible to implement? Regards, Chandana - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single Sign On Valve
On 19/04/2010 08:05, Arnab Ghosh wrote: Hello Friends, I want to know about the Single Sign On Valve. Why/when should we use this valve?? I have already studied the documentation about this. But I haven't got a clear idea about it. Is there any relation of Single-Sign-On with session management?? When a user logs onto one webapp, they are also authenticated to other webapps with the same authentication method when the SSO valve is configured on a Host. p signature.asc Description: OpenPGP digital signature
Re: Single sign on issue with Tomcat and Apache
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]
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. 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
Re: Single sign on issue with Tomcat and Apache
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
Re: Single sign on issue with Tomcat and Apache
- Original Message - From: sridharmnj [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign on issue with Tomcat and Apache
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) 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. p 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
Re: Single sign on issue with Tomcat and Apache
Well, Johnny, we seem to agree.. Johnny Kewl wrote: - Original Message - From: sridharmnj [EMAIL PROTECTED] 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: [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]
Re: Single sign on issue with Tomcat and Apache
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 [EMAIL PROTECTED] 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: [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-tp17633391p17677750.html Sent from the Tomcat - User mailing list archive at Nabble.com
RE: Single sign on issue with Tomcat and Apache
From: sridharmnj [mailto:[EMAIL PROTECTED] Subject: Re: Single sign on issue with Tomcat and Apache Is it a better idea to move apache pages (bbb) into the tomcat (ccc)? If you're not using httpd for anything other than serving static content, then yes, get rid of it. Tomcat by itself does that quite well. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign on issue with Tomcat and Apache
sridharmnj wrote: - 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 [...] Hmm, I am sorry, if I mislead you. aaa is based on FORM authentication only and my client doesnot want to chage it. As Johnny and I are telling you in different words but with the same meaning, you are mixing two different kinds of authentication, and Apache (and the browser) unfortunately never see the authentication that happens with the Tomcat FORM method. And there is even no way, at the Tomcat level, to pass this information back to Apache (and neither does it need to be passed back to Apache, it should passed to the browser, see below). Or, let me put this another way, there is no simple way, using just the standard Apache and Tomcat configuration and standard add-on modules. If your client absolutely wants to keep the FORM authentication for aaa, and still wants to have a single-sign-on between the 3 areas aaa/ccc/bbb, then the other solution would be to change the authentication method for bbb and ccc. One general solution, roughly outlined in one of my previous emails : do all the authentication(s) at the Apache level, and pass the Apache authentication to Tomcat. You could do something, at the Apache level, that will authenticate the user always with a form (for aaa/bbb/ccc), and it could even be the same look as the login.jsp currently used on Tomcat/aaa. And it would be single-sign-on for all aaa/bbb/ccc. That would be the cleanest solution. (Note : the Tomcat applications would still be protected and authenticated. They just would no longer handle the login dialog themselves). Or, another solution : cut out Apache, and use Tomcat also as the HTTP server for the static pages of bbb. If what happens on Apache is no more than serving static html pages for bbb, Tomcat can do that too. And this way, you could protect bbb by a Tomcat-level Basic authentication, and it would also fall within your Tomcat single-sign-on. Or, leave Apache in-between, but have it pass all requests for bbb to Tomcat also (like it does for aaa and ccc), and serve the static pages from Tomcat, subject to basic authentication on Tomcat. This way, after the first authentication, no matter where in aaa/bbb/ccc, Tomcat would know and keep the authentication even if you later switch between aaa/bbb/ccc. In Basic authentication, it is the browser basically that decides to send the authorization : Basic U3JpZGabkyuUZXN0aW5n header, in function of what it knows (that the realm xxx requires authorization). It knows that, because in a previous attempt to access this same realm, it received a 401 response from the server, telling him authorization required for realm xxx. But in your case, when the user accesses aaa first, the browser never receives a 401 response, so it never knows that it must send the authorization header, and it never does. So when you go from aaa to bbb, it does not send the header either, even if the realm is the same, because it does not know (yet) that an authorization is required. The result is that Apache sends back a 401 response then, and the result of that is that the browser pops up the login dialog (again). That's a bit simplified, but it's the essence. On the other hand, Tomcat *never* sends any authentication information back to Apache. When you access ccc first, it is Tomcat that sends the 401 response to the browser, and that is how *the browser* then knows. Apache never knows. [...] André - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign on issue with Tomcat and Apache
Many thanks!! I am planning to follow the below approach only. Or, leave Apache in-between, but have it pass all requests for bbb to Tomcat also (like it does for aaa and ccc), and serve the static pages from Tomcat, subject to basic authentication on Tomcat. This way, after the first authentication, no matter where in aaa/bbb/ccc, Tomcat would know and keep the authentication even if you later switch between aaa/bbb/ccc. I am planning to move bbb (Apache static pages) to Tomcat and make it Tomcat Basic authentication. So I can access aaa/bbb/ccc. This seems to be the best solution for me. (Because, there are some other applications which are running on tomcat and this may be useful for future enhancements also) Now I am looking on feasibility of moving those pages to Tomcat. Thanks to you all and thanks to the wonderful forum. awarnier wrote: sridharmnj wrote: - 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 [...] Hmm, I am sorry, if I mislead you. aaa is based on FORM authentication only and my client doesnot want to chage it. As Johnny and I are telling you in different words but with the same meaning, you are mixing two different kinds of authentication, and Apache (and the browser) unfortunately never see the authentication that happens with the Tomcat FORM method. And there is even no way, at the Tomcat level, to pass this information back to Apache (and neither does it need to be passed back to Apache, it should passed to the browser, see below). Or, let me put this another way, there is no simple way, using just the standard Apache and Tomcat configuration and standard add-on modules. If your client absolutely wants to keep the FORM authentication for aaa, and still wants to have a single-sign-on between the 3 areas aaa/ccc/bbb, then the other solution would be to change the authentication method for bbb and ccc. One general solution, roughly outlined in one of my previous emails : do all the authentication(s) at the Apache level, and pass the Apache authentication to Tomcat. You could do something, at the Apache level, that will authenticate the user always with a form (for aaa/bbb/ccc), and it could even be the same look as the login.jsp currently used on Tomcat/aaa. And it would be single-sign-on for all aaa/bbb/ccc. That would be the cleanest solution. (Note : the Tomcat applications would still be protected and authenticated. They just would no longer handle the login dialog themselves). Or, another solution : cut out Apache, and use Tomcat also as the HTTP server for the static pages of bbb. If what happens on Apache is no more than serving static html pages for bbb, Tomcat can do that too. And this way, you could protect bbb by a Tomcat-level Basic authentication, and it would also fall within your Tomcat single-sign-on. Or, leave Apache in-between, but have it pass all requests for bbb to Tomcat also (like it does for aaa and ccc), and serve the static pages from Tomcat, subject to basic authentication on Tomcat. This way, after the first authentication, no matter where in aaa/bbb/ccc, Tomcat would know and keep the authentication even if you later switch between aaa/bbb/ccc. In Basic authentication, it is the browser basically that decides to send the authorization : Basic U3JpZGabkyuUZXN0aW5n header, in function of what it knows (that the realm xxx requires authorization). It knows that, because in a previous attempt to access this same realm, it received a 401 response from the server, telling him authorization required for realm xxx. But in your case, when the user accesses aaa first, the browser never receives a 401 response, so it never knows that it must send the authorization header, and it never does. So when you go from aaa to bbb, it does not send the header either, even if the realm is the same, because it does not know (yet) that an authorization is required. The result is that Apache sends back a 401 response then, and the result of that is that the browser pops up the login dialog (again). That's a bit simplified, but it's
Re: Single sign on issue with Tomcat and Apache
- 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 ;) 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]
RE: Single sign on issue with Tomcat and Apache
Hi. I saw your ongoing discussion, and maybe I can contribute something, but I need some more info before. Here is what you explained before : a) You have one site aaa.com to which users access this way : user --- tomcat aaa.com b) and another site bbb.com to which users access this way : 1) static content : user -- Apache bbb.com 2) dynamic content : user - Apache --- mod_jk --- tomcat bbb.com Is it really like described above ? I am asking all of this because there are some things in your explanation that are difficult to understand, like : if Apache and Tomcat are on the same machine, they cannot both be answering on port 80, so users must be accessing aaa.com:8080 or something like that, no ? And if there are 2 Tomcats on different machines - or even 2 virtual servers in one Tomcat - then it does not seem possible that they are sharing one set of user credentials. So what is the real layout ? Is all of that running on one single server ? Do you really have 2 separate Tomcat virtual hosts (or real separate Tomcat hosts), one for aaa.com and one for bbb.com ? or do you have one single Apache with two virtual servers aaa.com and bbb.com, and one single Tomcat with a single Host ? Do users really go directly to Tomcat aaa.com on port 80, or do they anyway alsways go through an Apache/mod_jk to reach aaa.com ? Other question : are the two site names really of the form company1.com and company2.com ? or is it more something like site1.company.com and site2.company.com ? (That's important because in the second case company.com would be a common domain, but that does not work for just com). André - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign on issue with Tomcat and Apache
- Original Message - From: André Warnier [EMAIL PROTECTED] To: users@tomcat.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, June 05, 2008 1:06 AM Subject: RE: Single sign on issue with Tomcat and Apache Hi. I saw your ongoing discussion, and maybe I can contribute something, but I need some more info before. Here is what you explained before : a) You have one site aaa.com to which users access this way : user --- tomcat aaa.com b) and another site bbb.com to which users access this way : 1) static content : user -- Apache bbb.com 2) dynamic content : user - Apache --- mod_jk --- tomcat bbb.com Is it really like described above ? Yes the exact architecture would help ;) I understand it like this browser -- Tomcat on aaa.com browser - Tomacat delivers web pages with links to bbb.com/image.jpg browser --- Apache on bbb.com with images and stuff (that wont authenticate) Reason is browser will not return auth and cookies that belong to domain aaa.com to bbb.com What (I think) may work is what you have indicated user - Apache (bbb.com) --- mod_jk --- tomcat aaa.com All links now to bbb.com and JK setup to talk to aaa.com Images on Apache and servlet JKMounted on aaa.com The browser will return Basic header and cookies... so I think Apache auth modules and tomcat on SingleSignOn will work. All assuming this can be setup and if the images are hosted remotely that the Sp can set up JK etc. But is webapp cannot be changed and images are hardcoded in servlet... I think he's snookered and probably has to lose authentication on Apache. Thats how I understand it... Maybe? --- 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]
Re: Single sign on issue with Tomcat and Apache
Johnny Kewl wrote: - Original Message - From: André Warnier [EMAIL PROTECTED] To: users@tomcat.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, June 05, 2008 1:06 AM Subject: RE: Single sign on issue with Tomcat and Apache Hi. I saw your ongoing discussion, and maybe I can contribute something, but I need some more info before. Here is what you explained before : a) You have one site aaa.com to which users access this way : user --- tomcat aaa.com b) and another site bbb.com to which users access this way : 1) static content : user -- Apache bbb.com 2) dynamic content : user - Apache --- mod_jk --- tomcat bbb.com Is it really like described above ? Yes the exact architecture would help ;) I understand it like this browser -- Tomcat on aaa.com browser - Tomacat delivers web pages with links to bbb.com/image.jpg browser --- Apache on bbb.com with images and stuff (that wont authenticate) Reason is browser will not return auth and cookies that belong to domain aaa.com to bbb.com What (I think) may work is what you have indicated user - Apache (bbb.com) --- mod_jk --- tomcat aaa.com All links now to bbb.com and JK setup to talk to aaa.com Images on Apache and servlet JKMounted on aaa.com The browser will return Basic header and cookies... so I think Apache auth modules and tomcat on SingleSignOn will work. All assuming this can be setup and if the images are hosted remotely that the Sp can set up JK etc. But is webapp cannot be changed and images are hardcoded in servlet... I think he's snookered and probably has to lose authentication on Apache. Thats how I understand it... Maybe? There are too many known unknowns at the moment to propose something precise. If there is only a single Tomcat with a single localhost Host and two webapps, then it would simplify the domain stuff and the SingleSignOn at that end. The general schema I am thinking about, if .. , is - all requests go through Apache, and from there to Tomcat or not - Tomcat allows only calls from Apache (IP filter) - Apache does all the authentication - mod_jk will pass the Apache user-id to Tomcat for requests that go there - the Apache config for Tomcat-destined links is of the kind Location (or LocationMatch) .. SetHandler Jakarta-servlet Authentication stuff.. Require ... /Location I'm not quite sure if for the static stuff you can combine JkUnMount's with a Location like above, but it's worth a try. Interesting anyway, and it kinds of fits with something I should get busy with in a few weeks. André - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign on issue with Tomcat and Apache
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, June 05, 2008 2:54 AM Subject: Re: Single sign on issue with Tomcat and Apache Johnny Kewl wrote: - Original Message - From: André Warnier [EMAIL PROTECTED] To: users@tomcat.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, June 05, 2008 1:06 AM Subject: RE: Single sign on issue with Tomcat and Apache Hi. I saw your ongoing discussion, and maybe I can contribute something, but I need some more info before. Here is what you explained before : a) You have one site aaa.com to which users access this way : user --- tomcat aaa.com b) and another site bbb.com to which users access this way : 1) static content : user -- Apache bbb.com 2) dynamic content : user - Apache --- mod_jk --- tomcat bbb.com Is it really like described above ? Yes the exact architecture would help ;) I understand it like this browser -- Tomcat on aaa.com browser - Tomacat delivers web pages with links to bbb.com/image.jpg browser --- Apache on bbb.com with images and stuff (that wont authenticate) Reason is browser will not return auth and cookies that belong to domain aaa.com to bbb.com What (I think) may work is what you have indicated user - Apache (bbb.com) --- mod_jk --- tomcat aaa.com All links now to bbb.com and JK setup to talk to aaa.com Images on Apache and servlet JKMounted on aaa.com The browser will return Basic header and cookies... so I think Apache auth modules and tomcat on SingleSignOn will work. All assuming this can be setup and if the images are hosted remotely that the Sp can set up JK etc. But is webapp cannot be changed and images are hardcoded in servlet... I think he's snookered and probably has to lose authentication on Apache. Thats how I understand it... Maybe? There are too many known unknowns at the moment to propose something precise. If there is only a single Tomcat with a single localhost Host and two webapps, then it would simplify the domain stuff and the SingleSignOn at that end. The general schema I am thinking about, if .. , is - all requests go through Apache, and from there to Tomcat or not - Tomcat allows only calls from Apache (IP filter) - Apache does all the authentication - mod_jk will pass the Apache user-id to Tomcat for requests that go there - the Apache config for Tomcat-destined links is of the kind Location (or LocationMatch) .. SetHandler Jakarta-servlet Authentication stuff.. Require ... /Location Yes, I think you right, if Apache is fronting the whole thing, then it may as well do all the auth stuff... This TC mailing list is great, theres a fantastic user knowledge base in this list. It almost like every other discipline has converged around TC. I beginning to think you could ask any question in this group, PHP, Ruby whatever, and it would probably get answered ;) Thanks --- 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]
RE: Single sign on issue with Tomcat and Apache
what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single sign on issue with Tomcat and Apache
Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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]
RE: Single sign on issue with Tomcat and Apache
and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single sign on issue with Tomcat and Apache
I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - 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-tp17633391p17636089.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]
Re: Single sign on issue with Tomcat and Apache
I'll first admit that I've never used single sign-on, so most of this is educated conjecture on my part. Hopefully it'll spark some discussion in the right direction. Your right -- jvm version is not going to make a difference with the issue you are seeing. Plus upgrading the jvm may break the nine year old app -- an excellent case to be made to your client/boss for rewriting/upgrading the old app. The real problem is how the single sign-on id is getting from aaa.com to bbb.com. Cookies won't work as the browser won't return a cookie for aaa.com to bbb.com. That's a security problem if it does. That leaves URL rewriting. Are you doing anything to make sure the URLs for bbb.com have the single sign-on id in the url? Seems like that's the only way for bbb.com to know it's getting a request from a previously authenticated user. --David sridharmnj wrote: I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - 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
Re: Single sign on issue with Tomcat and Apache
My understanding: When server receives a request for a secured resource first time (depending on url-pattern and security constraint settings in web.xml), first it asks for credentials using dialog box if its BASIC authentication or login form if its FORM authenticatin and performs authentication based on Realm (JDBC or JNDI or memory). If the user is authenticated successfully, it sets the Principal object in the request (you can see this using request.getUserPrincipal()). For subsequent requests, it checks everytime for the Principal object and flow continues. When SingleSignOn valve (server.xml) is enabled, Tomcat allows the user to navigate to other app (which is deployed in the same server) with out prompting for authentication details again. Actually it shares the Principal object in the request. In my case as I am already authenticated in aaa.com, I am able to access bbb.com's dynamic data (which is deployed in tomcat) without providing the authentication details second time. But not able to access the bbb.com's static data which is deployed in apache. In normal flow, (without SSO), if I authenticate bbb.com's apache pages (using httpd and .htaccess), I could navigate to Tomcat's pages without providing the authentication details. Means, here apache is caching credentials using SOME mechanism (not only cookies. But something else.. I am not sure..this) and tomcat is using those credentials and not asking for authentication. I need the reverse functionality. Means, when I provide credentials in aaa.com (Tomcat Form based authentication) I should be able to navigate to bbb.com's apache pages. (anyhow I am able to access bbb.com's tomcat pages). I am sorry for lengthy message. But I tried to explain complete scenario. David Smith-2 wrote: I'll first admit that I've never used single sign-on, so most of this is educated conjecture on my part. Hopefully it'll spark some discussion in the right direction. Your right -- jvm version is not going to make a difference with the issue you are seeing. Plus upgrading the jvm may break the nine year old app -- an excellent case to be made to your client/boss for rewriting/upgrading the old app. The real problem is how the single sign-on id is getting from aaa.com to bbb.com. Cookies won't work as the browser won't return a cookie for aaa.com to bbb.com. That's a security problem if it does. That leaves URL rewriting. Are you doing anything to make sure the URLs for bbb.com have the single sign-on id in the url? Seems like that's the only way for bbb.com to know it's getting a request from a previously authenticated user. --David sridharmnj wrote: I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security
Re: Single sign on issue with Tomcat and Apache
sridharmnj wrote: My understanding: When server receives a request for a secured resource first time (depending on url-pattern and security constraint settings in web.xml), first it asks for credentials using dialog box if its BASIC authentication or login form if its FORM authenticatin and performs authentication based on Realm (JDBC or JNDI or memory). If the user is authenticated successfully, it sets the Principal object in the request (you can see this using request.getUserPrincipal()). For subsequent requests, it checks everytime for the Principal object and flow continues. Pure basics. I'll only say that with BASIC authentication, user credential are transmitted to the server on _every_ request -- even for images, javascript and css. When SingleSignOn valve (server.xml) is enabled, Tomcat allows the user to navigate to other app (which is deployed in the same server) with out prompting for authentication details again. Actually it shares the Principal object in the request. Right, but http is a stateless protocol and the client still has to provide something to let the server know it's been there before. In the absence of url rewriting, it's usually a cookie. Cookies can't cross domains. In my case as I am already authenticated in aaa.com, I am able to access bbb.com's dynamic data (which is deployed in tomcat) without providing the authentication details second time. But not able to access the bbb.com's static data which is deployed in apache. I'm getting that nagging feeling in the back of my head there's a combination of Apache Httpd and Apache Tomcat here. If that's the case could you clarify what service is providing what resources? In normal flow, (without SSO), if I authenticate bbb.com's apache pages (using httpd and .htaccess), I could navigate to Tomcat's pages without providing the authentication details. Means, here apache is caching credentials using SOME mechanism (not only cookies. But something else.. I am not sure..this) and tomcat is using those credentials and not asking for authentication. Since Apache *Httpd* is using BASIC, and every request includes credentials, this is normal. Apache *Tomcat* would receive the same credentials in the BASIC auth header. I need the reverse functionality. Means, when I provide credentials in aaa.com (Tomcat Form based authentication) I should be able to navigate to bbb.com's apache pages. (anyhow I am able to access bbb.com's tomcat pages). I am sorry for lengthy message. But I tried to explain complete scenario. David Smith-2 wrote: I'll first admit that I've never used single sign-on, so most of this is educated conjecture on my part. Hopefully it'll spark some discussion in the right direction. Your right -- jvm version is not going to make a difference with the issue you are seeing. Plus upgrading the jvm may break the nine year old app -- an excellent case to be made to your client/boss for rewriting/upgrading the old app. The real problem is how the single sign-on id is getting from aaa.com to bbb.com. Cookies won't work as the browser won't return a cookie for aaa.com to bbb.com. That's a security problem if it does. That leaves URL rewriting. Are you doing anything to make sure the URLs for bbb.com have the single sign-on id in the url? Seems like that's the only way for bbb.com to know it's getting a request from a previously authenticated user. --David sridharmnj wrote: I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's
Re: Single sign on issue with Tomcat and Apache
PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - 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-tp17633391p17637401.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]
Re: Single sign on issue with Tomcat and Apache
. --David sridharmnj wrote: I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - 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-tp17633391p17637575.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org
Re: Single sign on issue with Tomcat and Apache
: I'll first admit that I've never used single sign-on, so most of this is educated conjecture on my part. Hopefully it'll spark some discussion in the right direction. Your right -- jvm version is not going to make a difference with the issue you are seeing. Plus upgrading the jvm may break the nine year old app -- an excellent case to be made to your client/boss for rewriting/upgrading the old app. The real problem is how the single sign-on id is getting from aaa.com to bbb.com. Cookies won't work as the browser won't return a cookie for aaa.com to bbb.com. That's a security problem if it does. That leaves URL rewriting. Are you doing anything to make sure the URLs for bbb.com have the single sign-on id in the url? Seems like that's the only way for bbb.com to know it's getting a request from a previously authenticated user. --David sridharmnj wrote: I hope you did not observe the following lines from my post. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. It is successfully running on those versions in production and client does not want to upgrade versions for time being. I dont think that the java version is creating any problem. Do you think so??? My problem is not related to Java version upgrades and its out of scope for discussion here. I am sure Java version update alone doesnot solve the issue. Propes, Barry L wrote: and you're stuck on Java 1.3.1 and cannot go forward? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:17 PM To: users@tomcat.apache.org Subject: RE: Single sign on issue with Tomcat and Apache Apache 2.0.50 Tomcat 5.0.27 Java 1.3.1 Propes, Barry L wrote: what versions are you using? Of each? -Original Message- From: sridharmnj [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:52 PM To: users@tomcat.apache.org Subject: Single sign on issue with Tomcat and Apache Hi, I am integrating two websites using single sign on. I have two sites namely aaa.com and bbb.com. When a user navigates from aaa.com, as he is already authenticated in it, he should be allowed to bbb.com without asking the credentials again. This is my requirement. aaa.com is based on Tomcat Form based authentication and working fine. bbb.com's static data is deployed on apache and it requires apache BASIC authentication (htttd, and .htaccess). And dynamic data is deployed on Tomcat and based on Tomcat BASIC authentication. If I access static data of bbb.com, it first asks for credentials (Using a popup), authenticates using mod_auth_mysql, and once the user is authenticated, it is storing credentials in browser cache. When I navigate to dynamic content which is in tomcat, still its working without asking credentials twice. (I ensured that realm-name in web.xml and AuthName in .htaccess file are same). I enabled SingleSignOn valve in server.xml file, and trying to access bbb.com from aaa.com. When I try to access dynamic data of bbb.com from aaa.com, as both are based on Tomcat security, they are sharing the browser cached credentials. (Though one is based on form and another is based on basic authentication model). But, when I try to access bbb.com's static data (which is in apache) from aaa.com, again its asking credentials, using a popup. bbb.com is an old project which was developed around 9 yrs ago and I am not allowed to modify/reengineer the architecture. Could any one please guide me in right direction. I appreciate your help. Thanks, Sridhar -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17633391.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] - 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-tp17633391p17633917.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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Single Sign-On
I think via a lookup to an LDAP reference, but you have to know that LDAP group from your administrator. -Original Message- From: Andrew Hole [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 05, 2007 11:52 AM To: Tomcat Users List Subject: Single Sign-On Hello everybody! I have two applications: - J2EE Application on tomcat - Microsoft Navision How can I implement single sign-on integrated with Microsoft Active Directory? Microsoft Active Directory could be central autenthication service? Thanks - 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]
RE: Single Sign-On across multiple webapps
From: A Sunley [mailto:[EMAIL PROTECTED] Subject: Single Sign-On across multiple webapps I'm experiencing some problems implementing SSO across two webapps. You make no mention of having read the Tomcat documentation for SSO, let alone enabling it: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Single%20Sign%2 0On (Adjust the above for whatever version of Tomcat you're using, which you didn't bother to mention.) Does that help resolve your problem? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lb, lightbulb432 wrote: The requirement doesn't accept having two tables (i.e. userTableA and userTableB), partly because increased maintenance, the possibility of table definitions going out of sync, etc. CREATE VIEW, anyone? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1sVh9CaO5/Lv0PARAjCcAJ4gF601g5wChd1FQ1TodzPjKuQmpACgsEqq nD8wKTUJVWYkc5eGnA/mXt8= =FMuk -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
Views would definitely allow me to keep the two tables separate, but then I'd have to authenticate against the two source tables separately (i.e. each application would point to the source table rather than to the view). If pointing both applications to the common view, then doesn't the original problem exist? But that requirement is only justification for authenticating with more than two credentials. From a technical point of view, what would you have to override to get this to work? In a previous post, I said the following: I took a look at JAASRealm and its authenticate method only takes two parameters (username and credentials, which is really just a single password string). Is it possible to pass my other credentials to the JAASRealm so that I can pass everything at one time (username, password, other credentials) to the stored procedure, rather than - if I've interepreted this correctly - authenticating once through the JAAS username/password, then again through my stored procedure to cancel out the previous authentication. So if not JAASRealm, perhaps I need to look at something else to customize? I could of course implement my own authentication, but if I can get around this one shortcoming of the credentials concept being considered a password String rather than a generic Collection of multiple Objects, then I think I might be able to use Tomcat authentication. Christopher Schultz-2 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lb, lightbulb432 wrote: The requirement doesn't accept having two tables (i.e. userTableA and userTableB), partly because increased maintenance, the possibility of table definitions going out of sync, etc. CREATE VIEW, anyone? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1sVh9CaO5/Lv0PARAjCcAJ4gF601g5wChd1FQ1TodzPjKuQmpACgsEqq nD8wKTUJVWYkc5eGnA/mXt8= =FMuk -END PGP SIGNATURE- - 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-without-form-based-authentication-tf3805975.html#a12410535 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]
Re: Single-sign on without form-based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lb, lightbulb432 wrote: Views would definitely allow me to keep the two tables separate, but then I'd have to authenticate against the two source tables separately (i.e. each application would point to the source table rather than to the view). If pointing both applications to the common view, then doesn't the original problem exist? Don't do that. Create separate views for each of your applications, and use the app-appropriate view for authentication. If you think this sounds like too much trouble, you're right. Just remember that Tomcat implements the simplest thing that could possibly work wrt authentication. If you don't like it, you can always override the authentication mechanism with something else (securityfilter!) or hand-roll your own realm. I took a look at JAASRealm and its authenticate method only takes two parameters (username and credentials, which is really just a single password string). Is it possible to pass my other credentials to the JAASRealm so that I can pass everything at one time (username, password, other credentials) to the stored procedure, rather than - if I've interepreted this correctly - authenticating once through the JAAS username/password, then again through my stored procedure to cancel out the previous authentication. Uh, you could always pass a concatenated credential which includes more than just the password. For instance: JAASRealm.authenticate(username, appId + : + hash(password)); Then, in your stored procedure, tear apart the credential and use part of it as the app identifier. Or, put the appId into the username. Whatever you want to do. There are lots of options. So if not JAASRealm, perhaps I need to look at something else to customize? I could of course implement my own authentication, but if I can get around this one shortcoming of the credentials concept being considered a password String rather than a generic Collection of multiple Objects, then I think I might be able to use Tomcat authentication. You can still use Tomcat's authentication mechanism... you just might have to use your own Realm implementation. Frankly, the org.apache.catalina.Realm interface is baffling to me. One option is to create a Realm that extends JDBCRealm (or, better yet, DataSourceRealm) and override the authentication method to do your own SQL queries, but keep all the configuration options provided by the superclass. You can even add a configuration option by adding a mutator and accessor to specify the app's id. Then you can do something like this in your context.xml: Realm className=package.to.your.Realm // extends JDBCRealm driverName=org.gjt.mm.mysql.Driver connectionURL=jdbc:mysql://localhost/authority connectionName=test connectionPassword=test userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name appId=application-1 / Just make sure you have setAppId and getAppId methods on your Realm implementation, and then use them when you build your SQL query to verify a login. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1wuQ9CaO5/Lv0PARAh6IAKCIY9aMp59xFxXHIj9z4eCfF+SYngCeMfDF O1Gr8CyGEsukK3BFtBw5voQ= =Tzs2 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
Wow, those are good suggestions. I was thinking about the String concatenation, but didn't think it was worth considering further until you just mentioned it. So let me see if I have this straight: Anytime I want to use more than two credentials, I have to provide my own Realm implementation. But the only time I need to do the String concatentation is when at least one of the additional credentials (i.e. beyond username and password) is provided at request-time by the user, rather than at deployment-time? So for the example you gave with the appId property on my Realm implementation, I wouldn't need to do String concatentation because the user is only providing two credentials? But if the user were specifying what application they wanted to log into, then I'd have to concatenate that before passing to the authenticate method because Realm hasn't been instantiated with that information? If your HTML form has a j_username, j_password and myThirdCredential, where would you concatenate j_password and myThirdCredential? I'm guessing you'd also have to override the servlet pointed to by j_security_check - if I'm correct, how would you override this? (My guess is the servlet class pointed to by the text j_security_check is hardcoded somewhere within Tomcat?) Christopher Schultz-2 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lb, lightbulb432 wrote: Views would definitely allow me to keep the two tables separate, but then I'd have to authenticate against the two source tables separately (i.e. each application would point to the source table rather than to the view). If pointing both applications to the common view, then doesn't the original problem exist? Don't do that. Create separate views for each of your applications, and use the app-appropriate view for authentication. If you think this sounds like too much trouble, you're right. Just remember that Tomcat implements the simplest thing that could possibly work wrt authentication. If you don't like it, you can always override the authentication mechanism with something else (securityfilter!) or hand-roll your own realm. I took a look at JAASRealm and its authenticate method only takes two parameters (username and credentials, which is really just a single password string). Is it possible to pass my other credentials to the JAASRealm so that I can pass everything at one time (username, password, other credentials) to the stored procedure, rather than - if I've interepreted this correctly - authenticating once through the JAAS username/password, then again through my stored procedure to cancel out the previous authentication. Uh, you could always pass a concatenated credential which includes more than just the password. For instance: JAASRealm.authenticate(username, appId + : + hash(password)); Then, in your stored procedure, tear apart the credential and use part of it as the app identifier. Or, put the appId into the username. Whatever you want to do. There are lots of options. So if not JAASRealm, perhaps I need to look at something else to customize? I could of course implement my own authentication, but if I can get around this one shortcoming of the credentials concept being considered a password String rather than a generic Collection of multiple Objects, then I think I might be able to use Tomcat authentication. You can still use Tomcat's authentication mechanism... you just might have to use your own Realm implementation. Frankly, the org.apache.catalina.Realm interface is baffling to me. One option is to create a Realm that extends JDBCRealm (or, better yet, DataSourceRealm) and override the authentication method to do your own SQL queries, but keep all the configuration options provided by the superclass. You can even add a configuration option by adding a mutator and accessor to specify the app's id. Then you can do something like this in your context.xml: Realm className=package.to.your.Realm // extends JDBCRealm driverName=org.gjt.mm.mysql.Driver connectionURL=jdbc:mysql://localhost/authority connectionName=test connectionPassword=test userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name appId=application-1 / Just make sure you have setAppId and getAppId methods on your Realm implementation, and then use them when you build your SQL query to verify a login. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1wuQ9CaO5/Lv0PARAh6IAKCIY9aMp59xFxXHIj9z4eCfF+SYngCeMfDF O1Gr8CyGEsukK3BFtBw5voQ= =Tzs2 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To
Re: Single-sign on without form-based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lb, lightbulb432 wrote: Anytime I want to use more than two credentials, I have to provide my own Realm implementation. But the only time I need to do the String concatentation is when at least one of the additional credentials (i.e. beyond username and password) is provided at request-time by the user, rather than at deployment-time? Well, I think that if you are going to do your own Realm implementation, you're better off with my (long) suggestion from my previous post. The concatenation thing basically doesn't work... there's no way (unless you use javascript... shudder) to concatenate that information before the authenticator gets its hands on the credentials. So for the example you gave with the appId property on my Realm implementation, I wouldn't need to do String concatentation because the user is only providing two credentials? Correct. The big problem with the Realm interface is that it doesn't accept an HttpServletRequest object... you only have access to the information that Tomcat wants you to have (like the username and password, and some other stuff like the message digest to use... MAYBE). Like I said, the Realm interface is a bit baffling. But if the user were specifying what application they wanted to log into, then I'd have to concatenate that before passing to the authenticate method because Realm hasn't been instantiated with that information? Er, yeah, but I have no idea how you'd do that. When you write your own Realm, you're still just getting the information Tomcat is willing to supply. If you want to pass more arguments, I think you're talking about replacing the authentication Valve at that point. Good luck! ;) If your HTML form has a j_username, j_password and myThirdCredential, where would you concatenate j_password and myThirdCredential? I dunno. The plan goes like this: 1. Add the 3rd credential to your login form. 2. ??? 3. Profit. I'm guessing you'd also have to override the servlet pointed to by j_security_check - if I'm correct, how would you override this? You basically can't. (My guess is the servlet class pointed to by the text j_security_check is hardcoded somewhere within Tomcat?) I don't think it's a servlet... I think it's a Valve that intercepts requests to /j_security_check when applying authentication and authorization is appropriate for a particular (previously-requested) URL. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1y949CaO5/Lv0PARAhNbAKClocjf0+BChThtUij5UJFtU5wfxgCgw8x4 zAjGdSYzjSJS2ShblnECih4= =3r7s -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
Here's the case where three credentials are necessary: there is a requirement to host multiple applications on a single database, and data such as users are in a single, shared table. Therefore, someone logging into app A would enter username and password of user1 and pass1, and someone else logging into app B could also enter username as password user1 and pass1, but still be two separate entities. In the single database, the authentication table would have [User,Pass,App] as (user1,pass1,A), and (user1,pass1,B), which are two different and unrelated records. So even though the users are only entering two credentials into their respective applications' user interfaces, the application itself authenticates with Tomcat using three credentials. How could I make this work? The requirement doesn't accept having two tables (i.e. userTableA and userTableB), partly because increased maintenance, the possibility of table definitions going out of sync, etc. Thanks. Gregor Schneider wrote: however, i do not see any sense at all passing more tha two credentials (user, pass) to authenticate therefore, i suggest first thing you should do is to re-think the design of your application. -- View this message in context: http://www.nabble.com/Single-sign-on-without-form-based-authentication-tf3805975.html#a12374143 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]
Re: Single Sign On
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Single%20Sign%20On Gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Sign On
Andrew Hole wrote: Exists some way to implement Single Sign On without source code changes? Could you tell me a little bit about Single Sign On? Thanks a lot In many environments, but particularly in portal environments, it is desireable to have a user challenged to authenticate themselves only once over a set of web applications deployed on a particular virtual host. http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Single Sign On http://www.google.co.uk/search?q=tomcat+single sign on p smime.p7s Description: S/MIME Cryptographic Signature
Re: Single Sign On
Single sign on using valve is interesting, but is it possible use him if I have different application running in different tomcat instances? I think that only works with different applications under same tomcat instance. Thank you On 8/22/07, Pid [EMAIL PROTECTED] wrote: Andrew Hole wrote: Exists some way to implement Single Sign On without source code changes? Could you tell me a little bit about Single Sign On? Thanks a lot In many environments, but particularly in portal environments, it is desireable to have a user challenged to authenticate themselves only once over a set of web applications deployed on a particular virtual host. http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Single Sign On http://www.google.co.uk/search?q=tomcat+single sign on p
Re: Single Sign On
Andrew Hole wrote: Single sign on using valve is interesting, but is it possible use him if I have different application running in different tomcat instances? I think that only works with different applications under same tomcat instance. Thank you You might want to take a look at the JOSSO project: http://www.josso.org/ I have not used JOSSO myself (yet), and I'm not sure whether you will be able to use it without modifying your webapps (maybe with some custom valves, depending on how your applications perform authentication), but it should be worth a try. Edmund - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Sign On
On Wed, Aug 22, 2007 07:00, Andrew Hole [EMAIL PROTECTED] wrote: Single sign on using valve is interesting, but is it possible use him if I have different application running in different tomcat instances? I think that only works with different applications under same tomcat instance. For enterprise-wide single-sign-on to all web resources, whether applications or static content, and with support for a wide variety of web servers (including Tomcat, but also Apache HTTPD, Microsoft IIS, and others), take a look at any of the following: cosign - http://weblogin.org/ Pubcookie - http://www.pubcookie.org/ CAS - http://www.ja-sig.org/products/cas/ WebAuth - http://www.stanford.edu/services/webauth/ Mark Montague ITCS Web/Database Production Team The University of Michigan [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Single-sign on without form-based authentication
You could call the authenticate()-method from Tomcat's FormAuthenticator: http://tomcat.apache.org/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/authenticator/FormAuthenticator.html#authenticate(org.apache.catalina.HttpRequest,%20org.apache.catalina.HttpResponse,%20org.apache.catalina.deploy.LoginConfig) However, this will work in Tomcat only, and I'd rather implement a formbased login than to frickle (German expression for a quick dirty solution) my own solution. cheers Gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
Thanks for pointing me to that class. How can I specify my overriden version in a configuration file or programmatically so that it can be used? Also, I was looking into how to solve the problem from my original post, and came across the concept multiple times of providing my own Realm implementation. Could somebody describe the difference between your suggestion and implementing Realm? Are they mutually exclusive concepts? Are they unrelated to each other completely? Thanks. Gregor Schneider wrote: You could call the authenticate()-method from Tomcat's FormAuthenticator: http://tomcat.apache.org/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/authenticator/FormAuthenticator.html#authenticate(org.apache.catalina.HttpRequest,%20org.apache.catalina.HttpResponse,%20org.apache.catalina.deploy.LoginConfig) However, this will work in Tomcat only, and I'd rather implement a formbased login than to frickle (German expression for a quick dirty solution) my own solution. cheers Gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - 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-without-form-based-authentication-tf3805975.html#a10785065 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]
Re: Single-sign on without form-based authentication
in $CATALINA_HOME/server/lib/catalina.jar there's a file catalina.properties. There your will find the following entries: BASIC=org.apache.catalina.authenticator.BasicAuthenticator CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator DIGEST=org.apache.catalina.authenticator.DigestAuthenticator FORM=org.apache.catalina.authenticator.FormAuthenticator NONE=org.apache.catalina.authenticator.NonLoginAuthenticator Replace either Basic or FormAuthenticator with your own, put your jar into $CATALINA_HOME/server/lib, restart - voilá had to do that once, however, it's a bad hack On 5/24/07, lightbulb432 [EMAIL PROTECTED] wrote: implementation. Could somebody describe the difference between your suggestion and implementing Realm? Are they mutually exclusive concepts? Are they unrelated to each other completely? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JAASRealm That would be a better solution, though, however, I'm not sure if that could work with the architecture you described in your former post. cheers gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
I'll try to avoid the hack method if possible. Let me clarify the two requirements that my authentication process must meet. It must use an existing stored procedure that will return a login success/fail response, and it needs additional credentials (username, password, and at least one other field, if not more.) Which of the two suggestions should I be looking at? (JAASRealm or FormAuthenticator?) I can't tell the conceptual difference between these classes, and which can solve my problem. Also, is it correct to say that both suggestions are Tomcat-specific? (Realms and FormAuthenticator.) Thanks. Gregor Schneider wrote: in $CATALINA_HOME/server/lib/catalina.jar there's a file catalina.properties. There your will find the following entries: BASIC=org.apache.catalina.authenticator.BasicAuthenticator CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator DIGEST=org.apache.catalina.authenticator.DigestAuthenticator FORM=org.apache.catalina.authenticator.FormAuthenticator NONE=org.apache.catalina.authenticator.NonLoginAuthenticator Replace either Basic or FormAuthenticator with your own, put your jar into $CATALINA_HOME/server/lib, restart - voilá had to do that once, however, it's a bad hack On 5/24/07, lightbulb432 [EMAIL PROTECTED] wrote: implementation. Could somebody describe the difference between your suggestion and implementing Realm? Are they mutually exclusive concepts? Are they unrelated to each other completely? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JAASRealm That would be a better solution, though, however, I'm not sure if that could work with the architecture you described in your former post. cheers gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - 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-without-form-based-authentication-tf3805975.html#a10787517 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]
Re: Single-sign on without form-based authentication
Gregor Schneider wrote: Well, subclassing FormAuthenticator would be a hack, a Tomcat-only-solution and inho a bad one. therefore, take a look at JAASRealm and try to combine it with your existing login-procedure, meaning - Implement a JAASRealm - get the credentials from there (user, password) - do the JAAS-Authentication via Tomcat - if ok, call your stored procedure - if that returns ok, fine, otherwise invalidate the Session and react accordingly That's just a rough schema, but it's a start to give you one or two thoughts. BTW.m JAAS is not Tomcat-specific since JAAS is a Java-API which all servlet-containers implement (at least all the important ones, afaik): http://en.wikipedia.org/wiki/Java_Authentication_and_Authorization_Service hth gregor I was halfway through writing an almost identical answer, but I shall instead just add: I concur. p smime.p7s Description: S/MIME Cryptographic Signature
Re: Single-sign on without form-based authentication
at least you've saved *half* of the time ;) cheers greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single-sign on without form-based authentication
well, we can't tell you the whole desigh of your_app-to-be but gave you some starting-points. now it's up to you to use them. however, i do not see any sense at all passing more tha two credentials (user, pass) to authenticate therefore, i suggest first thing you should do is to re-think the design of your application. what i'm trying to tell you is the following: - authenticate via tomcat with user/pass - when this is ok, get additional credentials (i.e. banking-pin or whatsoever), call your stored-procedure - when this call is ok, everything is fine, go ahead - if the call fails, invalidate tomcat's session, kicking the user out hope you get the idea and i got you right cheers gregor -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Sign-on Configuration with Apache
Mark, Mark Thomas schrieb: When starting a new thread (ie sending a message to the list about a new topic) please do not reply to an existing message and change the subject line. To many of the list archiving services and mail clients used by list subscribers this makes your new message appear as part of the old thread. This makes it harder for other users to find relevant information when searching the lists. i am very sorry about this, i just forgot about the message id. I didn't mean to 'hijack' a thread... This is known as thread hijacking and is behaviour that is frowned upon on this list. Frequent offenders will be removed from the list. It should also be noted that many list subscribers automatically ignore any messages that hijack another thread. The correct procedure is to create a new message with a new subject. This will start a new thread. I will remember this for the future, and hope, that noone is offended, or angry... Shall I start a new thread with this question, or shall i leave it now, and just remember it for the future? Sorry again! Regards. alex - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Sign-on Configuration with Apache
When starting a new thread (ie sending a message to the list about a new topic) please do not reply to an existing message and change the subject line. To many of the list archiving services and mail clients used by list subscribers this makes your new message appear as part of the old thread. This makes it harder for other users to find relevant information when searching the lists. This is known as thread hijacking and is behaviour that is frowned upon on this list. Frequent offenders will be removed from the list. It should also be noted that many list subscribers automatically ignore any messages that hijack another thread. The correct procedure is to create a new message with a new subject. This will start a new thread. Mark tomcat-user-owner - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign-on with multiple Tomcats served via one Apache httpdserver
Thank you both for the replies Yes David, custom management of authentication is indeed an option but a bit painful if it can be avoided. CAS on the other hand just looks like what we need, and it's open source, and looks mature, we'll give it a go. Thanks again Aaron. On 29/03/06, Steele, Aaron [EMAIL PROTECTED] wrote: We are using CAS, http://www.ja-sig.org/products/cas/, for something similar. I do not know if its exactly what you need. It does not, I believe, share any session information besides the login info. Thank You, Aaron Steele YRI Enterprise Solutions https://ris.yumnet.com w: 972.338.6862 c: 817.401.0831 -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 1:25 PM To: Tomcat Users List Subject: Re: Single sign-on with multiple Tomcats served via one Apache httpdserver The single sign-on valve only really shares an authenticated session accross the contexts of one tomcat server. Most likely other tomcat servers only if they are clustered. But you have two separate, non-clustered tomcat's whose only commonality is the Apache front-end and the user realm database. I don't know of any way in which one would be aware of sessions created and trusted in the other. You might want to consider your own sign-on mechanism to support this. --David Nic Daniau wrote: Hi, believe it or not, this problem which I though to be a very standard one, didn't get a single reply?! Even if you know this can't be done, please tell me! Thanks a lot in advance. Configuration: a. Apache httpd 2.0 server (IP0, port 80) with some content served from /cms b. Worker to a Tomcat 4.1 running on a separate box (IP1:8080) mapped to /app1 c. Anpother worker to another Tomcat 5.5 running on separate box (IP2:8080) mapped to /app2 Both Tomcats are using the same configuration for security realm (pointing to the same DataSource parameters of course): Realm className= org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/default debug=99 userTable=corporate.dbo.t_userlogin userNameCol=c_username userCredCol=c_password userRoleTable=corporate.dbo.t_userpermission roleNameCol=c_rolename digest=md5/ and have their Single Sign-on valve turned on: Valve className=org.apache.catalina.authenticator.SingleSignOn debug=0/ However, if you're required to authenticate to access say, /app1/aSecure.jsp, you will be asked to authenticate again to access say, /app2/anotherSecure.jsp, though from the user point of view, this is the same username/password on the same URL. Is there a way to carry over the single sign-on from each Tomcat to the Apache server, so that /app2/anotherSecure.jsp can trust the authentication done while visiting /app1/aSecure.jsp, or should this be done in a completely different way? We have to keep those two separate Tomcats (distinct hardware, different versions, performance issues). Thanks for your help! Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This communication is confidential and may be legally privileged. If you are not the intended recipient, (i) please do not read or disclose to others, (ii) please notify the sender by reply mail, and (iii) please delete this communication from your system. Failure to follow this process may be unlawful. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single sign-on with multiple Tomcats served via one Apache httpd server
The single sign-on valve only really shares an authenticated session accross the contexts of one tomcat server. Most likely other tomcat servers only if they are clustered. But you have two separate, non-clustered tomcat's whose only commonality is the Apache front-end and the user realm database. I don't know of any way in which one would be aware of sessions created and trusted in the other. You might want to consider your own sign-on mechanism to support this. --David Nic Daniau wrote: Hi, believe it or not, this problem which I though to be a very standard one, didn't get a single reply?! Even if you know this can't be done, please tell me! Thanks a lot in advance. Configuration: a. Apache httpd 2.0 server (IP0, port 80) with some content served from /cms b. Worker to a Tomcat 4.1 running on a separate box (IP1:8080) mapped to /app1 c. Anpother worker to another Tomcat 5.5 running on separate box (IP2:8080) mapped to /app2 Both Tomcats are using the same configuration for security realm (pointing to the same DataSource parameters of course): Realm className= org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/default debug=99 userTable=corporate.dbo.t_userlogin userNameCol=c_username userCredCol=c_password userRoleTable=corporate.dbo.t_userpermission roleNameCol=c_rolename digest=md5/ and have their Single Sign-on valve turned on: Valve className=org.apache.catalina.authenticator.SingleSignOn debug=0/ However, if you're required to authenticate to access say, /app1/aSecure.jsp, you will be asked to authenticate again to access say, /app2/anotherSecure.jsp, though from the user point of view, this is the same username/password on the same URL. Is there a way to carry over the single sign-on from each Tomcat to the Apache server, so that /app2/anotherSecure.jsp can trust the authentication done while visiting /app1/aSecure.jsp, or should this be done in a completely different way? We have to keep those two separate Tomcats (distinct hardware, different versions, performance issues). Thanks for your help! Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single sign-on with multiple Tomcats served via one Apache httpdserver
We are using CAS, http://www.ja-sig.org/products/cas/, for something similar. I do not know if its exactly what you need. It does not, I believe, share any session information besides the login info. Thank You, Aaron Steele YRI Enterprise Solutions https://ris.yumnet.com w: 972.338.6862 c: 817.401.0831 -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 1:25 PM To: Tomcat Users List Subject: Re: Single sign-on with multiple Tomcats served via one Apache httpdserver The single sign-on valve only really shares an authenticated session accross the contexts of one tomcat server. Most likely other tomcat servers only if they are clustered. But you have two separate, non-clustered tomcat's whose only commonality is the Apache front-end and the user realm database. I don't know of any way in which one would be aware of sessions created and trusted in the other. You might want to consider your own sign-on mechanism to support this. --David Nic Daniau wrote: Hi, believe it or not, this problem which I though to be a very standard one, didn't get a single reply?! Even if you know this can't be done, please tell me! Thanks a lot in advance. Configuration: a. Apache httpd 2.0 server (IP0, port 80) with some content served from /cms b. Worker to a Tomcat 4.1 running on a separate box (IP1:8080) mapped to /app1 c. Anpother worker to another Tomcat 5.5 running on separate box (IP2:8080) mapped to /app2 Both Tomcats are using the same configuration for security realm (pointing to the same DataSource parameters of course): Realm className= org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/default debug=99 userTable=corporate.dbo.t_userlogin userNameCol=c_username userCredCol=c_password userRoleTable=corporate.dbo.t_userpermission roleNameCol=c_rolename digest=md5/ and have their Single Sign-on valve turned on: Valve className=org.apache.catalina.authenticator.SingleSignOn debug=0/ However, if you're required to authenticate to access say, /app1/aSecure.jsp, you will be asked to authenticate again to access say, /app2/anotherSecure.jsp, though from the user point of view, this is the same username/password on the same URL. Is there a way to carry over the single sign-on from each Tomcat to the Apache server, so that /app2/anotherSecure.jsp can trust the authentication done while visiting /app1/aSecure.jsp, or should this be done in a completely different way? We have to keep those two separate Tomcats (distinct hardware, different versions, performance issues). Thanks for your help! Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This communication is confidential and may be legally privileged. If you are not the intended recipient, (i) please do not read or disclose to others, (ii) please notify the sender by reply mail, and (iii) please delete this communication from your system. Failure to follow this process may be unlawful. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
