You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <da...@hotwaxmedia.com> on 2009/05/04 19:28:41 UTC
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
Re: Brainstorming: Security Requirements/Scenarios
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <da...@hotwaxmedia.com>
> 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" <da...@hotwaxmedia.com>
>>> 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
>>
>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adrian Crum <ad...@hlmksw.com>.
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" <da...@hotwaxmedia.com>
>>> 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
>>
>>
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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" <da...@hotwaxmedia.com>
>> 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
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <da...@hotwaxmedia.com>
> 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
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>>>>
>>>>>>
>>>>>
>>
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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" <da...@hotwaxmedia.com> 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
> >>>>>>
> >>>>>
> >>>>
> >
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>>>>>
>>>>>
>>>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adam Heath <do...@brainfood.com>.
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...
Code shouldn't be using GenericDelegator. It should be using
DelegatorInterface. Then this problem wouldn't be an issue.
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>>>>
>>>>
>>>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>>
>>>
>>
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>>
>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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
>>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com> wrote:
>
>> From: David E Jones <da...@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
>>>
>
>
>
Re: Brainstorming: Security Requirements/Scenarios
Posted by Adrian Crum <ad...@yahoo.com>.
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 <da...@hotwaxmedia.com> wrote:
> From: David E Jones <da...@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
> >
Re: Brainstorming: Security Requirements/Scenarios
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>