The idea I had in mind was having the ability to assign a filter to an entity for access control scenario 3 - http://docs.ofbiz.org/x/JR8. If a user isn't logged in then there is no filter assigned to the entity, so it operates normally.
Btw, I'm not going to write any code until we get all of the details worked out and finalize the design. -Adrian --- On Sat, 5/16/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: Saturday, May 16, 2009, 4:14 PM > > Sorry for not getting back to this sooner. I spent a little > too much time on it earlier this week and then got a bit > slammed with other things... > > I'm glad we're discussing this and not doing any of it > yet... there are some possibly big issues. > > The main one that concerns me is this question: what do > permissions on entities mean? If you don't have the > permission, are allowed to do anything with the entity? If > you are not logged in, what is allowed and what isn't? Do we > allow code to circumvent the entity security by explicitly > using a non-secure delegator object (which would be the > default if we allow any sort of extension to it to be > optional)? What about cases where there are multiple > delegators involved? > > Anyway, it all comes down to this: if we don't have > something in place for mandatory, always-on entity security, > then why have any at all? It would be too easy to just > circumvent the security by not having a user passed down, or > by not going through the access controlled delegator... and > it's even worse if we have to change existing to get it to > do that because then it's not just malicious code that gets > through this way, it is also any code that we (or anybody > with custom code) misses when migrating. I'd rather have a > design that eliminates or at least mitigates that risk. > > About the dependency issue, I'm not too worried about it... > that's just a matter of refactoring existing code, and no > matter how we support entity-level security some refactoring > and reorganizing of code will be necessary. > > Anyway, I like the ThreadLocal ExecutionContext because it > can be a lower level object used for common information, and > it can be setup to just always be there, and if there are > multiple delegator instances used by a certain code block > they will all see the same ExecutionContext. Of course, with > that approach we still have decide how the system should > behave if no user is logged in... I suppose we simply hope > that a service or something else has run that the > anonymous/non-user is allowed to access and that it has > inherited permissions for things it calls... otherwise the > non-user will probably never have permission to touch an > entity. > > One thing that crossed my mind with all of this, BTW, is > that maybe we should just not worry about the entity > security for now. We can implement it for other artifacts > and worry about the entity ones later on without affecting > the other stuff... > > -David > > > On May 16, 2009, at 1:43 PM, Adrian Crum wrote: > > > > > 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 > >>>>>>> > >>>>>> > >>>>> > >> > >> > > > > > > > >
