I've been thinking about this for a while, and I have a suggestion.
Items 2, 3, and 5 all include some kind of constraint on data accessed.
Although this constraint has been incorporated in the current permissions
logic, I don't believe it belongs there.
If you really think about it, the rule "User X can access records determined by
Constraint Z" is a business rule - not a security issue. To me, it's no
different than the status change validation logic, or a rule that says "An
order can't be shipped until it is packed."
I believe if we take this approach and separate the business logic from
permission checking, it will make things a lot less complicated. It might even
make things more flexible.
-Adrian
--- On Wed, 5/6/09, David E Jones <david.jo...@hotwaxmedia.com> wrote:
> From: David E Jones <david.jo...@hotwaxmedia.com>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: dev@ofbiz.apache.org
> Date: Wednesday, May 6, 2009, 12:51 PM
> 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
> >
