geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: Jetty and JACC
Date Tue, 02 Dec 2003 07:10:47 GMT
Hey Greg,

> -----Original Message-----
> From: Greg Wilkins []
> 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?

Theoretically, web permissions could be added from the normal policy
statement; I have to admit that this strikes me as unwieldy.

> 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.

I'm thinking that they wanted to have third party security
PolicyProviders plug in their own implementations; there are a few out
there already.

> 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?

I think that they assume that all the security roles should be known at
the time the web module is deployed.  These are the roles that are in
the DD.  I am not familiar w/ the concept of adding security roles to a
DD after it's been deployed.


View raw message