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
