geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Jetty and JACC
Date Sun, 23 Nov 2003 01:27:01 GMT
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.
> >
> >
> >
> >
> 

Mime
View raw message