geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Jetty and JACC
Date Sun, 23 Nov 2003 02:06:51 GMT


sorry to be slow on this, but I've got another week of a business
trip to go before I'm back on deck fully....

Have a quick look at JACC, my initial feeling is that it will probably
be worthwhile making sure that Authorization is more pluggable in the
webcontainer.  Currently Authentication is pretty much pluggable, but
there is no easy way to get between the web.xml security declarations
and the policing of them.

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?

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.

So if we are using JACC, then we would simply turn off the webtiers
own authorization and only let it do the authenticating.  We would then
force a filter to be applied to all requests that would do JACC authentication
and then annoint the thread and/or calling stack with the required
security context.


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
>> Get closer to the financial markets with Reuters Messaging - for more
>> information and to register, visit <>
>> 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.

View raw message