A common request that appears on the mailing list is the ability to filter records depending on the user. Let's say a salesperson can only see customers they are assigned to. Currently, you can filter on Party Role so the salesperson gets a list of customers, but that won't restrict the list to only that salesperson's customers.
A filter could be created that filters out customers related to the salesperson, and that filter could be assigned to the Party entity in the salesperson's permissions. If the salesperson isn't logged in, then they aren't going to see anything anyway. -Adrian --- On Sun, 5/17/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: Sunday, May 17, 2009, 1:26 AM > > Isn't that the opposite of what we want? Things should be > more > restricted if there is no user, and not less restricted. I > may be > misunderstanding what you mean by this though... > > -David > > > On May 16, 2009, at 6:28 PM, Adrian Crum wrote: > > > > > 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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
