Alan/David,
What will be the relationship between JAAS login module authentication and jacc WebRoleRefPermission checking? Pre-jacc, isCallerInRole () was implemented by examining the list of Principals representing roles that were populated by a JAAS login module at authentication time. With jacc, the checking is done by equating the role with a Permission and checking if the Principal of the caller has been granted the permission, so will JAAS login modules be granting a Permission for each role a user is in?
I'd like to start integrating Jetty's authentication mechanism with Geronimo's. I've had a quick look in the core security package. Anything special I need to know?
cheers Jan
David Blevins wrote:
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.
