I believe that no matter which method is used (process or artifact)
both would require similar access control logic to be implemented. I'm
not sure how this would look in the artifact system (Adrian can
comment on that), but in the process driven system there would be two
options.
1. For simple checking a record against a role table (take ContentRole
as an example for this discussion; note that content may or may not be
considered a simple check, that has yet to be discussed/designed) you
could define the process of update:content:data to use a common
RoleCheckingDa extension and set the allowed role type values. This
would remove the need for extra logic which would need to be
implemented in simple circumstances.
2. Custom DA logic would be attached; in the case of the
update:party:contact process, logic would be written to check first
the owner of the party vs the user attempting to run the process,
followed by checking to see if the user is an admin/owner of a group
which the party to update is a member of.
So to better answer your question, regardless of the type of system
used, this sort of access control would be available and part of the
application design. Based on what I have read so far, the artifact
driven model would require this logic to be implemented in multiple
places assuming you want the same control in multiple artifacts. Where
as in a process driven architecture you would connect this logic to
the process and then associate/check that process with multiple
artifacts.
Andrew
On May 4, 2009, at 2:39 PM, 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 <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
