Re: Brainstorming: Security Requirements/Scenarios

[David E Jones]

This is meant to include any and all aspects of authorization (access  
control). Nothing in here talks about how that will be implemented,  
and if possible we'll do it without any code.

On a general level these are ALL business rules, ie every aspect of  
authorization or access control. Think of the business rules as things  
written in plain english, as opposed to how they might be implemented  
technically... we can worry about that once we understand better what  
we want people to be able to do.

And yes, one of the goals I'd like to see for a big security change  
like this IS to support configuration of record-level access control  
and not just the over-simplified artifact level access control.

-David


On May 6, 2009, at 11:20 PM, Adrian Crum wrote:


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