This is just a concept in my head, and I haven't looked into it in any detail, so I might be missing something.
If a decorator's constructor took the singleton Delegator, a UserLogin GenericValue, and one of the context Maps, then it would have the objects it needs to do security checks and filter data, etc. There would be no need to change the API. Calling one of the existing makeValue or create methods would fail if the user didn't have the create permission for that entity. Calling the existing find methods would return only the records the user is allowed to access, etc. -Adrian --- On Thu, 5/14/09, David E Jones <[email protected]> wrote: > From: David E Jones <[email protected]> > Subject: Re: Brainstorming: Security Requirements/Scenarios > To: [email protected] > 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 > >>>>> > >>>> > >>> > >
