From: David E Jones <david.jo...@hotwaxmedia.com>
Subject: Re: Brainstorming: Security Requirements/Scenarios
To: dev@ofbiz.apache.org
Date: Thursday, May 14, 2009, 7:36 PM
I don't think there is a reason why we can't.
Why do a decorator object instead of just changing the
GenericDelegator? In order for this to do anything we'll
have to change EVERY call to a decorator method anyway...
-David
On May 14, 2009, at 9:08 AM, Adrian Crum wrote:
David,
In the paragraph where you talk about the
ExecutionContext (a good idea btw) you mention thread local
variables for the entities. On another Wiki page you said
making the Delegator security-aware would require
refactoring the Delegator.
Why can't we have a user-and-security-aware decorator
for the Delegator? The decorator could hold the
thread's variables, and delegate the entity engine calls to
the contained singleton delegator. All existing code would
treat it like a regular delegator.
-Adrian
David E Jones wrote:
I have added these to the OFBiz Security Refactor
page that Adrian started:
http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor
I also added a note that the implementation
details I wrote up do not support scenario #3. I'm not so
sure about how we're going to support that, but I'm thinking
about it and if anyone has any ideas they would be more than
welcome!
-David
On May 10, 2009, at 10:11 PM, David E Jones
wrote:
I think enough time has passed, but clearly if
anyone has any comments for configuration patterns please
speak up!
Now to the point: I propose that we use this
list as a set of requirements to use to evaluate all future
proposals for security improvements, especially related to
configuration of authorization.
Does anyone disagree with doing that? (If so
we should discuss it more as needed, and if needed also vote
on it)
-David
On May 6, 2009, at 1:51 PM, David E Jones
wrote:
I think the discussion about the "process"
versus "artifact" has resulted in consideration of a
"process" as one way to group artifacts, so there is no need
for separate items on this list that explicitly handle
processes (ie they are handled implicitly). Please let me
know if I'm misunderstanding that (especially Andrew, you've
been a big proponent of the process side of things).
On that note, are there any other patterns
or specific security requirements that others would like to
discuss? I don't think this is the sort of thing where we
need to discuss the merits of each, unless someone thinks
that we shouldn't bother with supporting any of these
patterns. These should just be "socked away" somewhere and
used while we're doing the design so we have something to
evaluate the design alternatives to, and make sure they
handle all of these scenarios (or that we decide that a
non-supported scenario is not important).
-David
On May 4, 2009, at 11:28 AM, David E Jones
wrote:
This thread is specifically for
discussing security requirements and security use scenarios
to drive OFBiz security functionality going forward. Please
keep other discussion in another thread.
These things tend to fall into two
categories: functionality access and record-level access, or
a combination of both. That is a high level generalization
so just warning you that what I list below may be limited by
my own blindness since I usually think in terms of those two
things for security configuration. In other words, that's
the point of this brainstorming thread.
To get things started, here are a few
I can think of and have heard from others, these are in no
particular order:
1. User X can use Artifact Y for
anything that artifacts supports and on any data (where
"artifact" is a screen, web page, part of a screen or page,
service, general logic, etc)
2. User X can use Artifact Y only for
records determined by Constraint Z
3. User X can use any artifact for
records determined by Constraint Z
4. Artifact Y can be used by any user
for any purpose it supports
5. Artifact Y can be used by any user
for only for records determined by Constraint Z
6. User X can use any artifact for any
record (ie superuser)
Okay, you can see that my initial pass
at this is sort of an enumeration of combinations effort. If
you can think of other general scenarios, please share!
Also, please feel free to share specific requirements that
are not in such generic terms (we can worry about putting
them in more generic terms like this later).
Thank You!
-David
