Do you really think the intent of the people discussing this is to
confuse people, or even to convince people?
Let's be realistic about this... the subject here is a complicated one
and there are lots of different issues related to it. Some points are
coming up but I don't think we've even scratched the surface yet.
Heck, I don't think there has even been enough time for some people to
get over this enough personally and emotionally so that a totally
objective and rational conversation can even happen.
If you're wanting to use something then the best thing to do is write
up what you're wanting to do with it, and what you'd like to see in
the security functionality in OFBiz.
Back to the being realistic thing... again I don't think ANY of us has
thought this through thoroughly enough, including brainstorming to
explore options and then decision making to decide on it. Keep in mind
that if we choose something in a hasty way, it'll just not live as
long in the project. In other words, if there are still major issues
we'll all be wanting something different in the near future again
anyway. For example, I still haven't had a chance to write up some
security related things that are related to this and that have been
discussed over the years and that I think are important if we're going
to have an approach to security that will really meet the needs and
wants of users. I'm guessing there are others in the same boat.
I agree with Adam on this one, I don't think it's wise to expect the
conversation to settle down or for any of us to have a good thorough
chance to think it through in less than 2-4 weeks.
-David
On May 4, 2009, at 7:00 AM, Anil Patel wrote:
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
