No you misunderstood me. I was referring to us agreeing in a previous
email that "it was a fair assessment". Hence the smiley. I think your
comparison here is correct. In the process driven model, the logic is
attached to the process, and the process is attached to various
artifacts. The "gatekeeper" indeed is the central holder of information.
However, I do believe your analogy is slightly off. Its more like
"Adrian wishes to start car X" the gatekeeper takes the information
from Adrian's "key" and says "Ok" or "Not Ok". The process is "start
car X", the credentials are the "ignition key".
Andrew
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
