I spent some time researching the GenericDelegator. I think I have come up with a solution.
First off, there are more than 2,000 references to GenericDelegator in the project. I'm sure there are many installations that have customizations that reference GenericDelegator also. Changing the GenericDelegator API to accommodate the new security design is not a good idea - it would break a lot of code. There is also an issue with cross-dependency. Any attempt to put security-related code in the GenericDelegator will fail because the security component is built after the entity component. If we changed GenericDelegator so that we can make per-thread instances of it, then the class could be extended to add the new design functionality. All existing code would still reference GenericDelegator, but it will actually be an extended version that is security-aware. I spent some time separating GenericDelegator's data out and put it in a separate class called DelegatorData. There is only one instance of DelegatorData per delegator name. GenericDelegator holds a reference to a DelegatorData instance, so everything still works the same. Now we can have more than one instance of GenericDelegator. We could extend GenericDelegator in the entityext component to make it security-aware. That would eliminate any cross-dependency issues. The dispatch context, request handler, etc would create instances of the extended GenericDelegator. What do you think? -Adrian --- On Thu, 5/14/09, David E Jones <david.jo...@hotwaxmedia.com> wrote: > From: David E Jones <david.jo...@hotwaxmedia.com> > Subject: Re: Brainstorming: Security Requirements/Scenarios > To: dev@ofbiz.apache.org > Date: Thursday, May 14, 2009, 7:36 PM > > I don't think there is a reason why we can't. > > Why do a decorator object instead of just changing the > GenericDelegator? In order for this to do anything we'll > have to change EVERY call to a decorator method anyway... > > -David > > > On May 14, 2009, at 9:08 AM, Adrian Crum wrote: > > > David, > > > > In the paragraph where you talk about the > ExecutionContext (a good idea btw) you mention thread local > variables for the entities. On another Wiki page you said > making the Delegator security-aware would require > refactoring the Delegator. > > > > Why can't we have a user-and-security-aware decorator > for the Delegator? The decorator could hold the > thread's variables, and delegate the entity engine calls to > the contained singleton delegator. All existing code would > treat it like a regular delegator. > > > > -Adrian > > > > > > David E Jones wrote: > >> I have added these to the OFBiz Security Refactor > page that Adrian started: > >> http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor > >> I also added a note that the implementation > details I wrote up do not support scenario #3. I'm not so > sure about how we're going to support that, but I'm thinking > about it and if anyone has any ideas they would be more than > welcome! > >> -David > >> On May 10, 2009, at 10:11 PM, David E Jones > wrote: > >>> I think enough time has passed, but clearly if > anyone has any comments for configuration patterns please > speak up! > >>> > >>> Now to the point: I propose that we use this > list as a set of requirements to use to evaluate all future > proposals for security improvements, especially related to > configuration of authorization. > >>> > >>> Does anyone disagree with doing that? (If so > we should discuss it more as needed, and if needed also vote > on it) > >>> > >>> -David > >>> > >>> > >>> On May 6, 2009, at 1:51 PM, David E Jones > wrote: > >>> > >>>> > >>>> I think the discussion about the "process" > versus "artifact" has resulted in consideration of a > "process" as one way to group artifacts, so there is no need > for separate items on this list that explicitly handle > processes (ie they are handled implicitly). Please let me > know if I'm misunderstanding that (especially Andrew, you've > been a big proponent of the process side of things). > >>>> > >>>> On that note, are there any other patterns > or specific security requirements that others would like to > discuss? I don't think this is the sort of thing where we > need to discuss the merits of each, unless someone thinks > that we shouldn't bother with supporting any of these > patterns. These should just be "socked away" somewhere and > used while we're doing the design so we have something to > evaluate the design alternatives to, and make sure they > handle all of these scenarios (or that we decide that a > non-supported scenario is not important). > >>>> > >>>> -David > >>>> > >>>> > >>>> On May 4, 2009, at 11:28 AM, David E Jones > wrote: > >>>> > >>>>> > >>>>> This thread is specifically for > discussing security requirements and security use scenarios > to drive OFBiz security functionality going forward. Please > keep other discussion in another thread. > >>>>> > >>>>> These things tend to fall into two > categories: functionality access and record-level access, or > a combination of both. That is a high level generalization > so just warning you that what I list below may be limited by > my own blindness since I usually think in terms of those two > things for security configuration. In other words, that's > the point of this brainstorming thread. > >>>>> > >>>>> To get things started, here are a few > I can think of and have heard from others, these are in no > particular order: > >>>>> > >>>>> 1. User X can use Artifact Y for > anything that artifacts supports and on any data (where > "artifact" is a screen, web page, part of a screen or page, > service, general logic, etc) > >>>>> > >>>>> 2. User X can use Artifact Y only for > records determined by Constraint Z > >>>>> > >>>>> 3. User X can use any artifact for > records determined by Constraint Z > >>>>> > >>>>> 4. Artifact Y can be used by any user > for any purpose it supports > >>>>> > >>>>> 5. Artifact Y can be used by any user > for only for records determined by Constraint Z > >>>>> > >>>>> 6. User X can use any artifact for any > record (ie superuser) > >>>>> > >>>>> Okay, you can see that my initial pass > at this is sort of an enumeration of combinations effort. If > you can think of other general scenarios, please share! > Also, please feel free to share specific requirements that > are not in such generic terms (we can worry about putting > them in more generic terms like this later). > >>>>> > >>>>> Thank You! > >>>>> -David > >>>>> > >>>> > >>> > >
