Am I correct in thinking that artifact driven approach naturally integrates the concept of allowing inherited permission checking by roles, but in the process-driven approach we would have to use something like the RoleCheckingDa API extension? So if I want to give an administrator access to all records in their district schools, but not to all records in the state, I would just have to attach that person (or their role?) to the district and it would all be handled, but in the process-driven case I would have to make a call to perform that check?
-Al On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <adrian.c...@yahoo.com> wrote: > > I don't see us agreeing on anything. I'm saying each artifact is > responsible for its own security. You're saying security is defined by a > process. > > If you were to view a collection of artifacts - each responsible for its > own security - defining some kind of process-driven security, then that > might be true. > > Applying your process-driven security design to the picture analogy (from > what I have gathered so far from your design), it would be like there is a > gatekeeper at the entrance to the picture. The gatekeeper says "Adrian > intends to start the car, does he have permission to do that?" The car has > no say in the matter. The gatekeeper controls everything. > > The inherent limitation to that design is, the gatekeeper has to account > for every motive I might have in interacting with every artifact in the > picture. That gatekeeper has a lot on its hands! > > I think it is simpler to have each artifact decide for itself what Adrian > can or cannot do with it. I believe that was what David was trying to > express when he said "it's the artifact we want the code attached to not the > permission itself." > > -Adrian > > > --- On Sun, 5/3/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote: > > > From: Andrew Zeneski <andrew.zene...@hotwaxmedia.com> > > Subject: Re: Domain Based Security ( was re: Authz...) > > To: dev@ofbiz.apache.org > > Date: Sunday, May 3, 2009, 11:00 PM > > I like to think of it more as process-driven permission vs > > artifact driven permissions, because the "permission > > string" is defined to match a specific process. Other > > than that I think we finally agreed on something.. Ha! :) > > > > On May 4, 2009, at 1:55 AM, Adrian Crum wrote: > > > > > > > > --- On Sun, 5/3/09, Andrew Zeneski > > <andrew.zene...@hotwaxmedia.com> wrote: > > >> The question I believe now is, which is better? I > > >> personally think in terms of processes which is > > why what I > > >> proposed was all process based. However, artifact > > based may > > >> be more granular, but possibly too granular. If I > > understand > > >> this right, artifact based we could potentially > > have > > >> different access requirements for every single > > >> form/screen/service/entity/etc; where in a process > > based > > >> system the developer would define the processes as > > part of > > >> the application and these processes could be > > shared across > > >> common artifacts (forms can share with screens > > that share > > >> with services, etc). > > >> > > >> Does this sound like a fair assessment? > > > > > > Yes it is. It boils down to permission-driven > > permissions, versus artifact-driven permissions. > > > > > > -Adrian > > > > > > > > > > > > > > > >
