geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Jetty and JACC
Date Mon, 01 Dec 2003 23:32:17 GMT

Alan,

I'm finally over my jet lag and trying to get my head
around the threads on JACC and work out what I need to
do to Jetty5 to better support it.

While I think I understand *what* JACC is trying to do,
I'm not sure I understand *why*!

Any chance I could get you to explain your view on the
why of JACC a bit more, so that I can better understand
the threads.   I've tried reading the spec, but it is
also about the what and not the why.   If you're not
the person to ask - any idea who is?


I can see two key aspects of JACC:

  1) Ensure that web tier authentication results in a
     JAAS Subject being created and associated with the
     handling thread.

  2) Conversion of web.xml authorization constraints
     into JACC persmissions which are policed by a
     JACC aware security policy manager.

I can see the reason for 1) which allows container managed
security to be applied to any action taken by a web tier thread.
In fact this should be specified by the servlet spec and I
hope it will be included in the next rev.

But I don't get the need for 2).  Isn't that just specifying
an implementation of the servlet spec?   Who cares if
web authorization is handled by the web container directly or
if the constraints are converted to permissions and then checked?

Surely all this authorization complexity is not there just
because there is no standard way to ask a Subject questions
about roles? To avoid asking this simple question, it appears
that we need to totally describe the authorization constraints
so that something that understands roles can do the checks.

Is there any other reason for authorizing via Web*Permissions
etc??   For example, why does JACC get involved with
WebUserDataPermissions?

Are there any other sources of Web*Permissions other than web.xml?
One of the biggest problems with web security is that it is opt-in
rather than opt-out. I see that JACC says that web.xml constraints
get added to the excluded policy statement.  Is there any mechanism
to allow web permissions to be added the normal policy statement?

So any light you (or others) can shine on this will certainly
help me understand the motivation for JACC and what problems it
is trying to solve.  Eitherway, I'll start looking at Jetty5 to
separate the Authentication and Authorization more so that
Authorization can be seperably pluggable.

cheers


PS.  I also have a real problem with language in the JACC spec
like:

   "When an auth-constraint names the reserved role-name, "*",
    all of the patterns in the containing security-constraint must
    be combined with all of the roles defined in the web application."

The problem is that "all of the roles" may either by very large
or totally undefined and dynamic in nature.  What do we do for a
web application that dynamically creates new roles?   Are we planning
to actually try to implement this impossible dream, or can we
propagate the meaning of '*' to our own Policy implementation?




Mime
View raw message