Thanks for continuing to push on this gentlemen - it's much appreciated. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com
o:801.649.6594 f:801.649.6595 ----- "David E Jones" <david.jo...@hotwaxmedia.com> wrote: > On a related note, instead of passing it around in the widget and > service contexts why not change those APIs as well? > > -David > > > On May 14, 2009, at 8:36 PM, David E Jones wrote: > > > > > 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 > >>>>>> > >>>>> > >>>> > >
