ExecutionContext is just a means of keeping track of the program flow - it doesn't include security.
-Adrian --- On Sat, 5/16/09, Harmeet Bedi <[email protected]> wrote: > From: Harmeet Bedi <[email protected]> > Subject: Re: Brainstorming: Security Requirements/Scenarios > To: [email protected] > Date: Saturday, May 16, 2009, 3:40 PM > Wondering what would the API > extension to GenericDelegator or DelegatorInterface look > like.. is it [get|set]ExecutionContext() or more ? > > > Any attempt to put security-related code in the > GenericDelegator will fail because the security component is > built after the entity component. > > perhaps this could be addressed by making ExecutionContext > an interface in entity component with implementation > injected on use by followon component. > > Harmeet > > ----- Original Message ----- > From: "Adrian Crum" <[email protected]> > To: [email protected] > Sent: Saturday, May 16, 2009 3:43:13 PM GMT -05:00 > US/Canada Eastern > Subject: Re: Brainstorming: Security > Requirements/Scenarios > > > 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 <[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 > > >>>>> > > >>>> > > >>> > > > > > > > >
