Anil, you mentioned a document. Can you send out the link? I'm sure it is in these threads somewhere but with all the traffic on this topic I cannot seem to find a link to the doc.
----- Original Message ----- From: "Anil Patel" <anil.pa...@hotwaxmedia.com> To: dev@ofbiz.apache.org Cc: "Anil Patel" <anil.pa...@hotwaxmedia.com> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain Subject: Re: Domain Based Security ( was re: Authz...) Over last few days this discussion has changed subject few times. This is going more on lines of "confuse them if you cannot convenience". The new security system proposal document, implementation code and code demonstrating its use, been out for more then week, All big names in community have had chance to see it. I will rather discuss on list of items that are so bad about new security system (which is now in proposal status). If Andrew or others who like it cannot solve or disprove them then either we will know that its bad and cannot be used. I like the system and will like to use it. Regards Anil Patel On May 4, 2009, at 2:35 AM, Adrian Crum 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 >>> >>> >>> >>> > > >
