Alan,
2. Authorization: JACC permissions checks by the servlet container.
This is going to require quite a bit of work deep in the internals of
Jetty to replace Jetty's tempest-tested security code, and therefore
some thorough analysis of what should be done, the best way to do it
and the implications for Jetty.
I've been reading the Jetty code, a real pleasure BTW, it seems that the
security handlers, authenticators, and realms are tightly integrated
with the server and context. A looser coupling would allow users to use
the same Jetty security paradigm that is currently in place, while
allowing one to snap in JACC if one so desired.
The realms are pretty loosely coupled as are the form/basic etc
authenticators, but the actual implementation of the servlet spec
security checking is, I agree, pretty fundamental to the context.
I've been working on this and will have some preliminary patches in a
few days. I am eager to hear your opinion.
Great! I look forward to it.
Not that it makes any difference whatsoever to the need to implement
it for Geronimo, but for my 2c, I think as a spec, JACC is a waste of
space: too detailed and addresses the wrong problem.
I am curious to know what J2EE security problem is out there that you
think still needs to be addressed. Just interested.
I just meant that I would rather see specifications that mandate an API
rather than an implementation.
IIUC, JACC allows third party enterprise security packages to be snapped
into J2EE servers. There are already third party vendors out there.
I do see that JAAC brings web.xml based security into line with standard
java permissions and therefore allows for pluggable security impls, but
there is something about the spec that doesn't sit right with me, but I
don't know that I can articulate right now. My reservations might be
being influenced by the fact that I find the spec to be written in an
impenetrable style.
cheers
Jan
