geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Security stuff
Date Wed, 12 May 2004 18:00:36 GMT

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










Mime
View raw message