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
