Hey Greg, > -----Original Message----- > From: Greg Wilkins [mailto:[EMAIL PROTECTED] > > 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. Regards, Alan
