On Apr 28, 2010, at 4:14 PM, Pid wrote: > On 28/04/2010 23:40, David Jencks wrote: >> I'd be curious how many of the features in securityfilter can be done with >> servlet 3 (which includes the ability for an app to programatically force a >> login) and jaspic (jsr 196) which provides for pluggable authentication >> dialogs between client and server (to overly simplify it). It looks to me >> as if all the features in your brief description are now supported by ee >> specs, which also offer the advantages of container managed authorization. > > Srv 3.0 /does/ cover some of the functions of securityfilter, but IMHO > the latter's been a home for things that the spec doesn't cover, but > that are common requirements anyway. > > It could now be a source of Tomcat integration with technologies like > OpenID & OAuth for example, if the existing experience of operating as a > Filter rather than a Valve wasn't of enough interest.
I'm well aware of the limitations of servlet 2.5 without jaspic. However, to use one of your examples, it's easy to write an OpenID jaspic server authentication module that lets you do container managed authentication and authorization using openid (see the geronimo-jaspi-openid component). There's also a SPNEGO auth module somewhere. Rather than telling me that old specs don't support a lot of stuff securityfilter does, I'd like to know specifically what securityfilter does that the new specs don't support. At this point I have no opinion on whether it would be a good idea for securityfilter to move to apache. One incubator project that might be somewhat related is Shiro (formerly jsecurity). I have no idea how similar the projects are. thanks david jencks > > > p > >> thanks >> david jencks >> >> On Apr 28, 2010, at 10:49 AM, Christopher Schultz wrote: >> >> All, >> >> Hello, I'm Chris Schultz, the maintainer of the securityfilter project >> (http://securityfilter.sourceforge.net/) and active member of the >> tomcat-user mailing list. >> >> I've been loosely following the plans for Tomcat 7 and was interested to >> see that there's an effort to convert existing Tomcat Valve components >> into Filters, I suppose to make them more flexible and also to increase >> portability. >> >> For those unfamiliar with the project, securityfilter is a filter-based >> implementation of authentication and authorization that aims to comply >> with the Java Servlet Specification while offering features above and >> beyond it. Most of our users have abandoned container-managed auth >> provided by containers such as Tomcat because of missing features (not >> specified by the servlet spec) such as "barge-in" logins, customized >> after-login pages, and customizability that doesn't tie the web >> application to any specific container. >> >> I inherited the existing securitfyilter code base from Max Cooper and >> I've been trying to improve the compliance with the servlet spec and to >> ensure support for the more recent versions of the spec (sf is mostly >> 2.3 compliant, but we're trying to fill-in all the holes). After adding >> a few features to the 2.x code base, I'm considering a full re-write of >> the code for a 3.x version that is more flexible than the current >> implementation. >> >> I was thinking that, as Tomcat contemplates a conversion of >> container-managed auth from a Valve to a Filter, securityfilter could >> possibly factor-into that conversion. I'd be happy to convert sf into an >> Apache commons/incubator project and have Tomcat use it for >> authentication and authorization. >> >> Mark Thomas has indicated his interest in discussing this possibility on >> the development list, so I'm presenting it to the group. I'd be happy to >> give more details about my current plans for sf, etc. but I figured that >> if there was significant interest in the Tomcat/ASF communities, we >> could discuss what feature set ought to be available. >> >> Please let me know if the community is interested in "adopting" >> securityfilter and, ultimately, using it in Tomcat. >> >> Thanks, >> -chris >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >>> > >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
