Greg, Jumping in for Alan to get you some quick answers. I'm sure Alan will chime in later.
On Sun, Nov 23, 2003 at 02:06:51AM +0000, Greg Wilkins wrote: > Will JACC require the servlets (etc.) to be run as part > of a Subject.doAs(...), or is it just sufficient to associate > an AccessControlContext with a thread? Associating the AccessControlContext with the thread is compliant, and *much* faster than a Subject.doAs. As Alan explained to me, Subject.doAs involves combinding all the protection domains in scope into one -- about a 100,000 nanoseconds. > If the former (and probably in the later), I think we may want to > consider putting much of JACC into a container supplied Filter, as > it has the right calling semantics. Also a filter will be more portable > between containers and is in line with some ideas floated on JSR154 > regarding pluggable authentication in the next rev of the servlet spec. A filter will work beatifly for checking WebResourcePermission and WebUserDataPermission. The WebRoleRefPermission is checked as the result of a isCallerInRole callback, so a little more magic will be required there. -David > Jan Bartel wrote: > >Alan, > > > >Just had a quick scan of the spec before I go off to my day job. Is it a > >fair summary to say the scope of the issue is this: > > > >1. conversion of web.xml declarations into jacc permissions > > and registration of same with external (in this case Geronimo) > > Policy provider > >2. registration by servlet container of various Policy context handlers, > > esp. a HttpServletRequest Policy handler > >3. servlet container enforced checking of jacc permissions at various > > points > >4. movement of the servlet container's existing security checking on > > URL patterns etc into an external Policy provider implementation > > > > > >Seems like the jacc spec crosses over with the servlet spec in regards > >URL pattern matching and security constraint specifications. This may be > >an issue. Also seems like this is a pretty deep, fundamental shift in > >the structure of the servlet container to support this stuff. > > > >This will need some thought. I'll forward this to Greg to get his > >feedback on it. > > > > > >Jan > > > > > >>>You don't necessarily have to replace a particular Jetty Handler. > >>>Handlers are arranged in a chain, so to introduce new behaviour it is > >>>possible to just insert another Handler in the chain. Not sure if > >>>this will be possible here or not. > >> > >> > >> > >>It's not possible since the web container must solely rely on the JACC > >>permission check. If I put a JaccHandler in the chain, after the > >>SecurityHandler, it effectively short circuits the JACC permission check. > >>If I put the JaccHandler before the SecurityHandler, it virtually removes > >>the SecurityHandler. > >> > >> > >>>Also, there is an access point into the web app context that is > >>>called as a thread enters and leaves a web app which might be another > >>>place to look at if you need to set up any thread local stuff (we've > >>>already subclassed the standard Jetty web app as > >>>o.a.g.w.jetty.JettyWebApplicationContext). > >> > >> > >> > >>Good idea. Thanks for the pointer. > >> > >> > >>>Finally, however it is done, we need to keep in mind that we must > >>>also be able to plug-in other web containers. > >> > >> > >> > >>Yep, I think I'm there on that account w/ the basic building blocks, > >>their > >>mbeans, and utility classes. > >> > >> > >>>Let me have a read of the JACC spec so I have a better understanding > >>>what is required and I can comment better. > >> > >> > >> > >>Some advice, skim chapter three. It's a tedious spec on how to translate > >>the descriptors into sets of Permissions. Chapter 4 is where the tire > >>hits > >>the road, more specifically section 4.2. > >> > >> > >>Regards, > >>Alan > >> > >> > >>---------------------------------------------------------------- > >>Visit our Internet site at http://www.reuters.com > >>Get closer to the financial markets with Reuters Messaging - for more > >>information and to register, visit <http://www.reuters.com/messaging> > >>Any views expressed in this message are those of the individual sender, > >>except where the sender specifically states them to be the views of The > >>Reuters Group. > > > > > > > > >
