See my comments inline.
> -----Original Message----- > From: Christopher Schultz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2008 8:50 PM > To: Tomcat Users List > Subject: Re: How to force HTTPS on some of Struts-based site > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gordon, > > Hyatt, Gordon wrote: > | The intent is as follows: > | > | For the main site: plain HTTP access > | > | For the administration and sample submission areas, require > | authentication over HTTPS > | > | Disallow DELETE and PUT methods from all areas. > > [snip] > > | <security-constraint> > | <display-name>Administration Methods</display-name> > | <web-resource-collection> > | <web-resource-name>admin methods</web-resource-name> > | <description/> > | <url-pattern>/admin/*</url-pattern> > | <http-method>GET</http-method> > | <http-method>POST</http-method> > | </web-resource-collection> > | <auth-constraint> > | <role-name>admin_user</role-name> > | </auth-constraint> > | <user-data-constraint> > | <transport-guarantee>CONFIDENTIAL</transport-guarantee> > | </user-data-constraint> > | </security-constraint> > > That ought to fill your first 2 requirements. In order to prohibit PUT > and DELETE, you'll need another <security-condstraint> section that > specified no valid roles for the PUT and DELETE methods. > > | I've also added a filter to capture all requests (/*) that checks the > | requested path; if that path is a "privileged" path (admin or > | submission), then check that the user is authenticated and within the > | specified role (as configured in the filter). > > This should not be necessary; the container should already handle the > role checking (it's already configured in web.xml). > > | I changed the role-name to * in the above auth-constraint and removed > | (commented out) the <login-config> section of web.xml. > > Why? > > | So my question is this: how do I force HTTPS on some portions of a > | Struts-based web site. With the filter, I can force authentication, but > | not the HTTPS constraint. > > <user-data-constraint> should be enough to make that happen. Are you > saying that a <security-constraint> with only the <transport-guarantee> > in it is not being respected by Tomcat? > > Which version? Can you post your new web.xml instead of the original one > that has since been modified? > I had everything working correctly using container-based security (using digested passwords), including denying DELETE and PUT requests. But, due to the "enhanced" password encryption requirements of this site (a requirements change near the time of delivery - a simple one-way digest was deemed insufficient), I cannot use container-based authentication. I won't go into too many details, but suffice it to say that the passwords can now be "easily discovered" - each password is encrypted with the exact same key. So I decided on the fallback to write a simple filter to handle the authentication and redirection with Struts-based forms (simply because the rest of the site uses Struts) and handle the actual authentication (including password encryption) in a Struts Action. In order for the filter to receive the request, I had to remove some of the container-based security (the PUT and DELETE security-constraint still exists). The only other way I could think of handling the password encryption scheme was to write a custom Realm, which at the time, seemed over-the-top to me. Looking back, perhaps a custom Realm would have been the way to go. Gord > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkf0KawACgkQ9CaO5/Lv0PBfQgCeLQFA0sJNAG7MfPoa2I52orWz > 20QAnjZd1EwJIEQoBzoK/g8nFmaGGuIh > =s08N > -----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]
