Alan D. Cabrera wrote:
I am eager to hear your opinion.
Jumping in to offer another opinion - warning long rant follows:
One of the reasons I have not progressed with JACC (other than total lack of time) is that I really just don't understand what it is trying to do.
If we look at Jetty's security layer, it has plugable Realms (including JAAS) and plugable authentication mechanisms (FORM, BASIC, DIGEST, ...). The main thing that is not pluggable is the security policy itself - as that is specified by the servlet spec.
But if the security module was to be made plugable, then as a black box, it would need an API that when presented with the question "Is it OK to let this request proceed" can respond with one of the following answers:
+ Yes. + Maybe if you answer this challenge + Maybe if you redirect to this page and authenticate there. + I don't want to talk about it on this insecure channel - redirect to this SSL listener. + No but you can try another identity + NO! and don't even think about asking again.
Then there are lots of little complications that make this black box needs to be a little grey. Things like clustering support for session based authentication and single sign on.
I don't see anything like the above in JACC - so I don't see that a container that uses JACC can avoid having it's own implementation of the web.xml based security policy.
But one thing that really is lacking with web.xml security is that it is not integrated with java.security. Thus you don't have fine grained control over your security.
When I heard of JACC - I did not expect to see extra permissions types added like it has - I expected extra grant clauses to be defined and integration with existing ones specified. For example, I was expectiong to be able to write a policy file like:
grant principal "admin_user"
{
permission java.io.FilePermission "/tmp/games", "read, write";
} grant request "/context/path/special/*"
{
permission java.io.FilePermission "/tmp/games", "read";
}This way a policy file could control what resources an executing servlet could access. The first example could easily be achieved simply by defining the link between servlet users/roles and javax Subjects/Principals etc.
Instead of this JACC gives us a whole bunch of new Permissions that really just encode what we already have in web.xml. So they are of no use to somebody writing a policy file and thus can't be used to control the permissions of code executed by a particular servlet request. There is no use granting access to a URL to a codebase as codebases don't access URLs!
If fact - I just don't understand who would use the JACC permissions - other than the implementer of the servlet container. But that implementation is already specified elsewhere and implemented - who cares if it uses permissions or not?
So what I think I need to understand JACC - is a motivation for it? What is it trying to do? why? and for who? If anybody has some example uses - that would be a great help, as I find the spec impossible - it is so busy giving the details of how - any mention of why is totally lost (at least for me).
cheers
