OFBiz › OFBiz - Dev

Brainstorming: Security Requirements/Scenarios

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

40 messages Options

David E Jones-3

Brainstorming: Security Requirements/Scenarios

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

Andrew Zeneski-2

Re: Brainstorming: Security Requirements/Scenarios

The list you have here seems to imply we have decided on an artifact
based security system, that is not the case. So far there are two
different styles being discussed one is artifact based where the other
is process based.

Andrew

On May 4, 2009, at 1:28 PM, 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
>

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

This is a great start! I have nothing to add.

-Adrian

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
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by Andrew Zeneski-2

That's great feedback Andrew. Could you put this in terms of one or
more items we can add to the list?

-David

On May 4, 2009, at 11:47 AM, Andrew Zeneski wrote:

> The list you have here seems to imply we have decided on an artifact
> based security system, that is not the case. So far there are two
> different styles being discussed one is artifact based where the
> other is process based.
>
> Andrew
>
> On May 4, 2009, at 1:28 PM, 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
>>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

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:

Andrew Zeneski-2

Re: Brainstorming: Security Requirements/Scenarios

Even if we were to continue to debate a process vs artifact based
system, the list below would pretty much be the same (s/artifact/
process/gi). That said, I think the list is fairly complete and I
can't think of anything else to add at this moment.

Andrew

On May 6, 2009, at 3: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
>>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

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 <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> 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
> >

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

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 <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Brainstorming: Security Requirements/Scenarios
>> To: [hidden email]
>> 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
>>>
>
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

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:

Jacques Le Roux

Re: Brainstorming: Security Requirements/Scenarios

Administrator

In reply to this post by David E Jones-3

I have a question about artifact and Freemarker template. In the description below is a Freemarker template considered as an
artifact ?
This question because in Freemarker template we may have several entry points for permission and we don't have an xsd to constraint
things.

Jacques

From: "David E Jones" <[hidden email]>

> 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
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

Yes, a FTL file could be an artifact. I'm not aware of any instances
where an entire FTL file is wrapped by a permission (although I think
there are places where parts of an FTL file do permission checks...
and that's a complicated issue for external security... those would
probably need to be split into multiple files, preferably referred to
through multiple screen defs).

-David

On May 11, 2009, at 1:31 AM, Jacques Le Roux wrote:

> I have a question about artifact and Freemarker template. In the
> description below is a Freemarker template considered as an artifact ?
> This question because in Freemarker template we may have several
> entry points for permission and we don't have an xsd to constraint
> things.
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>> 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
>
>

Jacques Le Roux

Re: Brainstorming: Security Requirements/Scenarios

Administrator

From: "David E Jones" <[hidden email]>
> Yes, a FTL file could be an artifact. I'm not aware of any instances
> where an entire FTL file is wrapped by a permission (although I think
> there are places where parts of an FTL file do permission checks...
> and that's a complicated issue for external security... those would
> probably need to be split into multiple files, preferably referred to
> through multiple screen defs).

That's is exactly how I was thinking it should be done (could it be another way ?)

Thanks

Jacques

> -David
>
>
> On May 11, 2009, at 1:31 AM, Jacques Le Roux wrote:
>
>> I have a question about artifact and Freemarker template. In the
>> description below is a Freemarker template considered as an artifact ?
>> This question because in Freemarker template we may have several
>> entry points for permission and we don't have an xsd to constraint
>> things.
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>> 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
>>
>>
>

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

I was thinking we could have some kind of security transform.

-Adrian

David E Jones wrote:

>
> Yes, a FTL file could be an artifact. I'm not aware of any instances
> where an entire FTL file is wrapped by a permission (although I think
> there are places where parts of an FTL file do permission checks... and
> that's a complicated issue for external security... those would probably
> need to be split into multiple files, preferably referred to through
> multiple screen defs).
>
> -David
>
>
> On May 11, 2009, at 1:31 AM, Jacques Le Roux wrote:
>
>> I have a question about artifact and Freemarker template. In the
>> description below is a Freemarker template considered as an artifact ?
>> This question because in Freemarker template we may have several
>> entry points for permission and we don't have an xsd to constraint
>> things.
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>> 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
>>
>>
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

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
>>>
>>
>

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

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
>>>>
>>>
>>
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

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
>>>>>
>>>>
>>>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

On a related note, instead of passing it around in the widget and
service contexts why not change those APIs as well?

-David

On May 14, 2009, at 8:36 PM, David E Jones wrote:

>
> 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
>>>>>>
>>>>>
>>>>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

This is just a concept in my head, and I haven't looked into it in any detail, so I might be missing something.

If a decorator's constructor took the singleton Delegator, a UserLogin GenericValue, and one of the context Maps, then it would have the objects it needs to do security checks and filter data, etc. There would be no need to change the API. Calling one of the existing makeValue or create methods would fail if the user didn't have the create permission for that entity. Calling the existing find methods would return only the records the user is allowed to access, etc.

-Adrian

--- On Thu, 5/14/09, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> 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
> >>>>>
> >>>>
> >>>
>
>

Tim Ruppert

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

Thanks for continuing to push on this gentlemen - it's much appreciated.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

----- "David E Jones" <[hidden email]> wrote:

> On a related note, instead of passing it around in the widget and
> service contexts why not change those APIs as well?
>
> -David
>
>
> On May 14, 2009, at 8:36 PM, David E Jones wrote:
>
> >
> > 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
> >>>>>>
> >>>>>
> >>>>
> >

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

Well, maybe because we don't have unlimited resources to rewrite
*everything.* ;-)

-Adrian

David E Jones wrote:

>
> On a related note, instead of passing it around in the widget and
> service contexts why not change those APIs as well?
>
> -David
>
>
> On May 14, 2009, at 8:36 PM, David E Jones wrote:
>
>>
>> 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
>>>>>>>
>>>>>>
>>>>>
>>
>
>