-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 3/30/2010 6:50 PM, Mark Thomas wrote: > On 30/03/2010 23:05, Christopher Schultz wrote: >> If Tomcat is moving to Filters rather than Valves, does that mean that >> Tomcat authentication will be done using Filters, or is there some other >> strategy in the works? > > The strategy is to move to filters. The tactics are somewhat lacking in > detail. Understood. >> I ask because a Filter-based authentication and authorization strategy >> would duplicate the work of securityfilter (and probably be more >> up-to-date, but that's beside the point). > > Potentially. I see security filter is essentially Apache licensed. Hmm. > I feel a Baldrick[1] moment coming on. Well, I'd have to talk to Max Cooper, the original owner of the project, but I suspect that we wouldn't mind if Tomcat just annexed the the sf code and eviscerated it as necessary. The cvs head is very stable, but I'm not happy with a lot of the stuff that's in there, such as the URL pattern matching code and the lack of extensibility in general (sure, you can plug-in your own Realms, but you can't really change the behavior of the Filter itself without just copying it and re-writing whatever you need). I'd be happy to have an off-list conversation about the current status, my thoughts on the possible direction(s) of the code, etc. >> I would actually prefer that Tomcat go with a Filter-based >> authentication strategy because of the flexibility which can be achieved >> by intercepting the call chain without having to dive into the internals >> of Tomcat. >> >> What's the plan for T7-auth? > > At the minute, implement JSR-196 once the Servlet 3.0 is completed (it > is very close) with a valve to filter move for authentication probably > pushed back to Tomcat 8. > > SecurityFilter is an obvious starting point. How do you feel about > contributing some patches with the aim of merging the SecurityFilter > code into Tomcat? Is it feasible to do this incrementally or would it > need to be in one big patch? Good question: Tomcat does a lot of stuff that sf doesn't. For example, we don't do CLIENT-AUTH, we don't do SSO, and the code hasn't been tested against the latest servlet spec (though little has changed in the last few versions relative to authentication and authorization). On the other hand, sf supports a lot of stuff Tomcat doesn't: "remember me", explicit after-login forward/redirect, pass-through request parameters to an explicit forward/redirect, drive-by authentication (i.e. no previous request for a protected resource is required in order to successfully login), and a Realm interface that is flexible enough to allow a Realm implementation to do all kinds of wonderful things like log the IP address of a failed login (because the Request object is passed-into the authentication method). So, I think the first thing to do would be to identify which feature set you want to target, and then decide if the code in sf is good enough and/or compatible for Tomcat's purposes. I'm not sure about the ASF's desires, but moving sf into the ASF proper and having Tomcat simply use it as its authentication and authorization strategy would be the best result for everyone: I would (probably) get more help with the code, Tomcat gets a shot in the arm in terms of functionality, and users retain the ability to use the library outside the context of Tomcat if they want to. Again, I'd be happy to talk off-list if you'd like to discuss this further. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuzUasACgkQ9CaO5/Lv0PCUkgCeLmLSEm6lR6yfNDmTmIOATymz tJwAn3Jt6rrdzu7T8UrjPmAc69J2WBSt =wF6E -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
