In the artifact-driven approach, the inheritance is from higher level
artifacts to lower level artifacts. So if I assign a user permission to
use a screen, that permission is inherited by all the artifacts the
screen contains. Contained artifacts can optionally override the
inherited permission.
So, no - the inheritance is not in user roles. However, user role
inheritance could be accommodated by the authentication mechanism.
-Adrian
Al Byers wrote:
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 <[email protected]> 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 <[email protected]> wrote:
From: Andrew Zeneski <[email protected]>
Subject: Re: Domain Based Security ( was re: Authz...)
To: [email protected]
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
<[email protected]> 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
