Greetings: As promised, i report back my solutions and hope this may help others. It turns out that there is also some issues directly related to Shale Dialog due to its current interactions with Jsf.
On Sat, 2005-06-11 at 08:47 -0600, Duong BaTien wrote: > On Fri, 2005-06-10 at 23:08 -0400, Frank W. Zammetti wrote: > > Duong BaTien wrote: > > > First, thanks for an extra help. > > > > No problem... I hope I can help further :) > > > > > The whole idea is to use SSL for confidential pages such as logon, > > > change username / password, edit profile with confidential data. Other > > > time some resources may just be protected by roles. The ideal situation > > > is to switch between SSL and Non-SSL using proper configuration on > > > stand-alone tomcat (not with tomcat and apache front end). > > > > So it is within the same webapp... I think Craig raised a valid point in > > that case... once the connection isn't secured, a would-be hacker can > > play some games by sniffing the wire. If security is important enough > > to encrypt certain pages, I would wonder if they really all should be > > encrypted. Let's move beyond that though because if that's your > > requirement than that's what you have to pull off :) > > > Yes, if everything is straight then our life is simpler isn't it? Some > files are too big and ssl will kill us in the business world. We protect > them using roles. > > > > The issue with standalone tomcat is that once the user is login under > > > SSL, all connections including public resources not protected by web.xml > > > after the SSL will be in SSL under the same application. > > A good solution was proposed by Steve Ditlinger in his JavaWorld paper (Feb 2002) and later evolved into sslext for Struts. The approach is quite easy to implement for any framework. This is what we do under Jsf. > > > I don't know what the spec says in this regard... this could be a by > > design mechanism, or it could be a bug in Tomcat. It might be worth > > researching though... you may be trying to fight something that is > > actually working as it is supposed to. > > > That is what a great developer community is about. Unfortunately, i am > not a hard core developer. > > > > I did that but the same issue of serving public resource with SSL still > > > persist after the SSL connection. Note: I just found out that i did > > > something wrong so i still have to qualify this result(?). > > > > When you say "public resource", what does that mean? Do you mean an > > unconstrained resource? > > > Yes, unconstrained resource. > > > > Because i have not been able to switch between ssl (not for the session > > > id but for Confidential data) and non-ssl connection, i work out the > > > second plan to use 2 web applications under the same tomcat host and use > > > tomcat SingleSignOn to co-ordinate user sessions under the 2 web apps: 1 > > > for SSL and 1 for non SSL. > > The SSO solution is a step more complex than the dynamic switching between SSL and non-ssl. It is justifiable when you want a quick integration among different web applications. See below our simple 2-step approach. > > Just a shot in the dark, but what if you define a constraint on your > > UNPROTECTED resources and define the transport guarantee as NONE? It > > sounds like the user will always pass through a secured page first, so > > they would have a session established and be authenticated to a user > > realm, so I *think* it will work... I wonder if that will force it to a > > non-SSL state though? > > No, this won't work - at least under our own tests. > > This is a good suggestion. I wil try this simple and easy thing first. > > > > That is what i hope to get some help. The issue has nothing to do with > > > shale. I am sure that some one has done this successfully with > > > standalone tomcat. I appreciate any help. I ask this list under Shale > > > because under the scenario as explained below that i need 2 web apps, i > > > want to use shale for both. > > > > Certainly asking this on the Tomcat list would probably get you some > > further help... There may be some folks that that already know the ins > > and outs of Tomcat specifically better than I do. > > > As i said i picked up a thread called Forced Non-SSL from tomcat user > list and promised to report back the result of my investigation for the > benefit of others. > > > > Yes, this is what i expect. But the reality is that the non-protected > > > resources NOT under <security-constraint> are served by ssl once ssl is > > > used, at least as i see it and also reported by another user in tomcat > > > user list under standalone tomcat 5.5.9. > > The redirect must involve both protocol (http or https) and the service port if you use tomcat. Our solution is to use linux iptables to re direct the ports for tomcat and build the dynamic switching between http and https into 2 steps: 1) A quick, easy approach, and probably the only solution if you also use Shale Dialog: 1.1) Divide the application into 2 sections, ssl section (say under /secure) and non-ssl section (say under /public). 1.2) Let tomcat control and guarantee the ssl connection for secure section. 1.3) Make well-defined entry and exit points between the 2 sections. >From https, you move to http by hard coding the exit pages (such as a response to a user click to move back to http section or a logoff page). The hard code is done with protocol and port number together with the exit page. 1.4) If you use Shale Dialog under ssl, it seems to us that you must complete the involved Shale Dialog process before you can click different resources. If the Shale Dialog cannot find a jsf outcome configured under its dialog-config, it will issue an exception. Our work around solution is to define a common page for all Dialog entry points. Once the user is in a dialog process, he/she must complete the process and/or cancel to exit the Dialog. ==> Suggestion: A more general approach may be to enable the Dialog looking at Jsf navigation configuration and serve the requested resources while marking its exit and re-entry points. This feature seems easier to implement than a suggested more elaborate feature of multiple dialog.data for different fragments on the same page. 2) a proper dynamic switching that involves the requested page, its desired protocol and its service port. Again, this approach is not fully exploitable if you also use current Shale Dialog due to the reason mentioned above. Hope a brief outline of our solution may be useful and/or save others some time. BaTien DBGROUPS > > > Interesting... That *sounds* like a bug, but again, I'd be interested to > > know what the spec says. Might be exactly what *should* happen. But if > > you can, give my suggestion a try... Could be a simple fix :) > > > Yes, this is my intention. I will report back to this list my > investigation and the result i choose since i am planning to use shale > for a production project by the end of this year. > > > > Yes, i know and did that under pure html for testing. I ask for Jsf > > > because if i have to go to the route of having 2 web applications: 1 for > > > ssl connection and 1 for non-ssl connection, then i want to further > > > explore if i can use shale for both rather than ssl application for just > > > simple workaround. > > > > Gotcha. Let's see if we can't get it working the way you expected > > though, and the way I would have expected it too... we might both learn > > something here :) > > > I hope the list won't mind for the question predominantly tomcat and > related to shale only at a higher level. > > BaTien > DBGROUPS > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
