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]
