On 6/10/05, Duong BaTien <[EMAIL PROTECTED]> wrote: > Hello Craig: > > Using Shale, could you show how to code simple container-managed login > form with j_username, j_password, and j_security_check and shed some > light on the following attempt. > > Specifically, i am attempting to use simple tomcat 5.5.9 SingleSignOn to > dynamically switching between SSL application and non-SSL application > under the same host: > > 1) Non-SSL application: > 1.1) For protected resources, using roles but, not under SSL the app > will check user SSO cookie. If not existed, it direct user to SSL logon. > If the cookie existed, SingleSignOn will take care of the role > protection. > 1.2) For using SSL resources such as login, editProfile using Shale > Dialog, etc, it will put a cookie having user current requested page for > the SSL application to return to the non-SSL protocol. > > 2) SSL application: Get the user remote page for switching back to HTTP > after the SSL session. All resources will be protected by SSL and roles. > > Behind both applications is tomcat JDBCRealm, for now, to a single data > source. > > P.S: I tried RequestDispatcher using Shale preprocess command to direct > all pages not under the SSL secure directory, and let tomcat handle > SSL-protected pages. But this does not solve the problem that once the > user is connected using SSL, the SSL connection stays on with non-ssl > pages. Is there any simpler and/or better approach? JOSSO is the next > level up that i do not have resource for now. Besides, i want to use > Shale for both non-SSL and SSL applications. >
I'm afraid I am about two years out of date on SSO support in Tomcat (or any other app server for that matter), but it would seem this sort of issue doesn't have a lot to do with Shale, and does have a lot to do with how Tomcat implements it -- you might try the Tomcat user list for specific assistance. Personally, I have yet to convince myself that switching from SSL back to non-SSL (say, just using SSL for the login dialog so that the password is not in clear text) doesn't expose you to session hijacking, because your session id after the switchback is still in cleartext. Therefore, I haven't paid much attention to technologies that attempt to let you do this ... you might look at adapting something like SSLExt to work with JSF instead of Struts 1.x. But I've never looked at it; I only know it exists. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
