Greetings: As promised, i report back my solutions and hope this may help others.
On Mon, 2005-06-06 at 07:42 -0600, Duong BaTien wrote: > > On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: > > Almost. (I think) > > > Thanks. I will try the workaround and report to the list for the > benefits of others. > > BaTien > DBGROUPS > > > You can't request any pages under /WEB-INF. Security constraints are only > > for > > the incoming URL - not urls obtained by getRequestDispatcher() > > > > -Tim > > > I know. These are my protected pages and i want to make sure that they > must go through my presentation engine (Jsf + Tiles). > > BaTien > > > Duong BaTien wrote: > > > On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: > > > > > >> From a config point of view no. The "simple workaround" > > >>- Ditch the web.xml config for requiring SSL > > >>- Create a filter which checks the scheme and URL - if the do not match > > >>what > > >>you desire - you can issue a redirect in the filter to https (or http) as > > >>desired > > >> > > >> > > >>-Tim > > > > > > > > > Hello Tim and other tomcat 5.5.9 experts: > > > > > > If i understand you correctly, you propose: > > > 1) set security constraint pages you want to run under ssl, such as: > > > <security-constraint> > > > <web-resource-collection> > > > <url-pattern>/WEB-INF/secure/*</url-pattern> > > > <http-method>POST</http-method> > > > <http-method>GET</http-method> > > > </web-resource-collection> > > > <user-data-constraint> > > > <transport-guarantee>CONFIDENTIAL</transport-guarantee> > > > </user-data-constraint> > > > </security-constraint> > > > > > > 2) Write a servlet filter to direct any url NOT under the > > > pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do > > > you have this code handy and want to share with others? > > > The re direct must include both desired protocol and service port as explained in a proposed solution 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. > > > The result will be: > > > 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the > > > container will force the user with its logon FORM, if the user is not > > > authenticated. If username/password is authenticated the page > > > logonSuccess.jsp wil be served. > > > 2) If you create a user session (e.g. a guestTag for collecting user > > > activities) while user is NOT authenticated, and the container now > > > authenticated the user after the request of logonSuccess.jsp, the > > > servlet spec will guarantee that the session visible to developer code > > > after login be the same session object that was created prior to SSL > > > login so there is no loss of session information. > > > 3) Since the security model does not apply to RequestDispatcher > > > according to serlet spec, the container will serve other requests under > > > standard http and NOT https as reported after the user was served the > > > logonSuccess.jsp. The desired protocol and service port must be explicitly specified for the requested page. Hope this may help and/or save others some time. BaTien DBGROUPS > > > 4) Only after the user is authenticated by the server, we can use > > > getUserPrincipal(), isUserInRole() to integrate container authentication > > > with programmatic authorization. Before that, only a generic guestTag > > > for recording user activities. > > > > > > Do i miss something? > > > > > > Thanks > > > > > > BaTien > > > DBGROUPS > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
