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
