Sam,
That's an interesting article, and very relevant for some security
related changes we've done in recent months.
I was going to say that this discussion about a new security approach
doesn't have much to do with that article since this discussion is
really just all about how to configure and/or program access control
to different parts of the system and the intent is to improve ease of
use rather than tightness or thoroughness of security.
However, thinking about it more there are certain things that may
actually lead to tighter and more thorough security. For example, the
discussion about "Domain-Based Security" is heading in the direction
of externalizing 99% of the security configuration from the code. This
is an idea that has been discussed a few times over the year and I've
always found it interesting, but we really haven't had super-critical
issues with the permission configuration and code stuff so not much
has been done about it.
If I understand right where Adrian is going with this thread it is to
just start with wanting to granular for flexibility r reasons and
instead of having permissions that each screen/sevice/etc checks just
have each screen/service/etc BE a permission of sorts. We wouldn't
have any permission related configuration or code in the screens/
services/etc except for a single attribute to flag whether permission
is required or not (ie a require-permission flag), which we would want
to be true by default. Now that the granularity issue is taken care of
the next step is to build stuff on top of it to help manage the
thousands of permissions that are now in the project... and THAT is
where things get fun an interesting.
Anyway, I'm planning to write-up more of this as soon as I get the
time... hopefully in the next couple of days because I think this is
important... but I'm behind enough that people are actually writing me
directly and complaining that I haven't reviewed their stuff... in
other words it seems there are expectations about related to what they
think I should be doing and I haven't lived up to their dreams.
Oh, back to the first point: this approach might actually increase the
tightness and thoroughness of security because the default constraint
will change from allowing anything unless the screen/service/etc
checks for a permission, to allowing nothing unless the person
creating the screen/service/etc designates that no permission is
required, or the user has permission for that artifact (either to use
in general, or to use for a specific set of records).
So yes, this article IS actually relevant to the discussion.
-David
On May 4, 2009, at 5:35 AM, Sam Hamilton wrote:
Not to get in the middle of this as to be honest I don't know enough
for most of this thread to make sense but when I saw this article http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php
it made me remember why everyone should be passionate about security
On 04/05/2009 14:35, "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
