OFBiz › OFBiz - Dev

Brainstorming: Security Requirements/Scenarios

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

40 messages Options

Adam Heath-2

Re: Brainstorming: Security Requirements/Scenarios

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.

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

Adam,

Thank you for pointing that out! That was the detail I was missing. Now I understand what David was saying.

Wow. We really painted ourselves into a corner with that one.

We should change that - regardless of the security refactor.

-Adrian

--- On Fri, 5/15/09, Adam Heath <[hidden email]> wrote:

> From: Adam Heath <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> Date: Friday, May 15, 2009, 1:26 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...
>
> Code shouldn't be using GenericDelegator. It should
> be using
> DelegatorInterface. Then this problem wouldn't be an
> issue.
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

I spent some time researching the GenericDelegator. I think I have come up with a solution.

First off, there are more than 2,000 references to GenericDelegator in the project. I'm sure there are many installations that have customizations that reference GenericDelegator also. Changing the GenericDelegator API to accommodate the new security design is not a good idea - it would break a lot of code.

There is also an issue with cross-dependency. Any attempt to put security-related code in the GenericDelegator will fail because the security component is built after the entity component.

If we changed GenericDelegator so that we can make per-thread instances of it, then the class could be extended to add the new design functionality. All existing code would still reference GenericDelegator, but it will actually be an extended version that is security-aware.

I spent some time separating GenericDelegator's data out and put it in a separate class called DelegatorData. There is only one instance of DelegatorData per delegator name. GenericDelegator holds a reference to a DelegatorData instance, so everything still works the same. Now we can have more than one instance of GenericDelegator.

We could extend GenericDelegator in the entityext component to make it security-aware. That would eliminate any cross-dependency issues. The dispatch context, request handler, etc would create instances of the extended GenericDelegator.

What do you think?

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

Harmeet Bedi

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

Wondering what would the API extension to GenericDelegator or DelegatorInterface look like.. is it [get|set]ExecutionContext() or more ?

> Any attempt to put security-related code in the GenericDelegator will fail because the security component is built after the entity component.

perhaps this could be addressed by making ExecutionContext an interface in entity component with implementation injected on use by followon component.

Harmeet

----- Original Message -----
From: "Adrian Crum" <[hidden email]>
To: [hidden email]
Sent: Saturday, May 16, 2009 3:43:13 PM GMT -05:00 US/Canada Eastern
Subject: Re: Brainstorming: Security Requirements/Scenarios

I spent some time researching the GenericDelegator. I think I have come up with a solution.

First off, there are more than 2,000 references to GenericDelegator in the project. I'm sure there are many installations that have customizations that reference GenericDelegator also. Changing the GenericDelegator API to accommodate the new security design is not a good idea - it would break a lot of code.

There is also an issue with cross-dependency. Any attempt to put security-related code in the GenericDelegator will fail because the security component is built after the entity component.

If we changed GenericDelegator so that we can make per-thread instances of it, then the class could be extended to add the new design functionality. All existing code would still reference GenericDelegator, but it will actually be an extended version that is security-aware.

I spent some time separating GenericDelegator's data out and put it in a separate class called DelegatorData. There is only one instance of DelegatorData per delegator name. GenericDelegator holds a reference to a DelegatorData instance, so everything still works the same. Now we can have more than one instance of GenericDelegator.

We could extend GenericDelegator in the entityext component to make it security-aware. That would eliminate any cross-dependency issues. The dispatch context, request handler, etc would create instances of the extended GenericDelegator.

What do you think?

-Adrian

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

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by Adrian Crum-2

Sorry for not getting back to this sooner. I spent a little too much
time on it earlier this week and then got a bit slammed with other
things...

I'm glad we're discussing this and not doing any of it yet... there
are some possibly big issues.

The main one that concerns me is this question: what do permissions on
entities mean? If you don't have the permission, are allowed to do
anything with the entity? If you are not logged in, what is allowed
and what isn't? Do we allow code to circumvent the entity security by
explicitly using a non-secure delegator object (which would be the
default if we allow any sort of extension to it to be optional)? What
about cases where there are multiple delegators involved?

Anyway, it all comes down to this: if we don't have something in place
for mandatory, always-on entity security, then why have any at all? It
would be too easy to just circumvent the security by not having a user
passed down, or by not going through the access controlled
delegator... and it's even worse if we have to change existing to get
it to do that because then it's not just malicious code that gets
through this way, it is also any code that we (or anybody with custom
code) misses when migrating. I'd rather have a design that eliminates
or at least mitigates that risk.

About the dependency issue, I'm not too worried about it... that's
just a matter of refactoring existing code, and no matter how we
support entity-level security some refactoring and reorganizing of
code will be necessary.

Anyway, I like the ThreadLocal ExecutionContext because it can be a
lower level object used for common information, and it can be setup to
just always be there, and if there are multiple delegator instances
used by a certain code block they will all see the same
ExecutionContext. Of course, with that approach we still have decide
how the system should behave if no user is logged in... I suppose we
simply hope that a service or something else has run that the
anonymous/non-user is allowed to access and that it has inherited
permissions for things it calls... otherwise the non-user will
probably never have permission to touch an entity.

One thing that crossed my mind with all of this, BTW, is that maybe we
should just not worry about the entity security for now. We can
implement it for other artifacts and worry about the entity ones later
on without affecting the other stuff...

-David

On May 16, 2009, at 1:43 PM, Adrian Crum wrote:

>
> I spent some time researching the GenericDelegator. I think I have
> come up with a solution.
>
> First off, there are more than 2,000 references to GenericDelegator
> in the project. I'm sure there are many installations that have
> customizations that reference GenericDelegator also. Changing the
> GenericDelegator API to accommodate the new security design is not a
> good idea - it would break a lot of code.
>
> There is also an issue with cross-dependency. Any attempt to put
> security-related code in the GenericDelegator will fail because the
> security component is built after the entity component.
>
> If we changed GenericDelegator so that we can make per-thread
> instances of it, then the class could be extended to add the new
> design functionality. All existing code would still reference
> GenericDelegator, but it will actually be an extended version that
> is security-aware.
>
> I spent some time separating GenericDelegator's data out and put it
> in a separate class called DelegatorData. There is only one instance
> of DelegatorData per delegator name. GenericDelegator holds a
> reference to a DelegatorData instance, so everything still works the
> same. Now we can have more than one instance of GenericDelegator.
>
> We could extend GenericDelegator in the entityext component to make
> it security-aware. That would eliminate any cross-dependency issues.
> The dispatch context, request handler, etc would create instances of
> the extended GenericDelegator.
>
> What do you think?
>
> -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
>>>>>>>
>>>>>>
>>>>>
>>
>>
>
>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

The idea I had in mind was having the ability to assign a filter to an entity for access control scenario 3 - http://docs.ofbiz.org/x/JR8. If a user isn't logged in then there is no filter assigned to the entity, so it operates normally.

Btw, I'm not going to write any code until we get all of the details worked out and finalize the design.

-Adrian

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

> From: David E Jones <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> Date: Saturday, May 16, 2009, 4:14 PM
>
> Sorry for not getting back to this sooner. I spent a little
> too much time on it earlier this week and then got a bit
> slammed with other things...
>
> I'm glad we're discussing this and not doing any of it
> yet... there are some possibly big issues.
>
> The main one that concerns me is this question: what do
> permissions on entities mean? If you don't have the
> permission, are allowed to do anything with the entity? If
> you are not logged in, what is allowed and what isn't? Do we
> allow code to circumvent the entity security by explicitly
> using a non-secure delegator object (which would be the
> default if we allow any sort of extension to it to be
> optional)? What about cases where there are multiple
> delegators involved?
>
> Anyway, it all comes down to this: if we don't have
> something in place for mandatory, always-on entity security,
> then why have any at all? It would be too easy to just
> circumvent the security by not having a user passed down, or
> by not going through the access controlled delegator... and
> it's even worse if we have to change existing to get it to
> do that because then it's not just malicious code that gets
> through this way, it is also any code that we (or anybody
> with custom code) misses when migrating. I'd rather have a
> design that eliminates or at least mitigates that risk.
>
> About the dependency issue, I'm not too worried about it...
> that's just a matter of refactoring existing code, and no
> matter how we support entity-level security some refactoring
> and reorganizing of code will be necessary.
>
> Anyway, I like the ThreadLocal ExecutionContext because it
> can be a lower level object used for common information, and
> it can be setup to just always be there, and if there are
> multiple delegator instances used by a certain code block
> they will all see the same ExecutionContext. Of course, with
> that approach we still have decide how the system should
> behave if no user is logged in... I suppose we simply hope
> that a service or something else has run that the
> anonymous/non-user is allowed to access and that it has
> inherited permissions for things it calls... otherwise the
> non-user will probably never have permission to touch an
> entity.
>
> One thing that crossed my mind with all of this, BTW, is
> that maybe we should just not worry about the entity
> security for now. We can implement it for other artifacts
> and worry about the entity ones later on without affecting
> the other stuff...
>
> -David
>
>
> On May 16, 2009, at 1:43 PM, Adrian Crum wrote:
>
> >
> > I spent some time researching the GenericDelegator. I
> think I have come up with a solution.
> >
> > First off, there are more than 2,000 references to
> GenericDelegator in the project. I'm sure there are many
> installations that have customizations that reference
> GenericDelegator also. Changing the GenericDelegator API to
> accommodate the new security design is not a good idea - it
> would break a lot of code.
> >
> > There is also an issue with cross-dependency. Any
> attempt to put security-related code in the GenericDelegator
> will fail because the security component is built after the
> entity component.
> >
> > If we changed GenericDelegator so that we can make
> per-thread instances of it, then the class could be extended
> to add the new design functionality. All existing code would
> still reference GenericDelegator, but it will actually be an
> extended version that is security-aware.
> >
> > I spent some time separating GenericDelegator's data
> out and put it in a separate class called DelegatorData.
> There is only one instance of DelegatorData per delegator
> name. GenericDelegator holds a reference to a DelegatorData
> instance, so everything still works the same. Now we can
> have more than one instance of GenericDelegator.
> >
> > We could extend GenericDelegator in the entityext
> component to make it security-aware. That would eliminate
> any cross-dependency issues. The dispatch context, request
> handler, etc would create instances of the extended
> GenericDelegator.
> >
> > What do you think?
> >
> > -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
> >>>>>>>
> >>>>>>
> >>>>>
> >>
> >>
> >
> >
> >
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

Isn't that the opposite of what we want? Things should be more
restricted if there is no user, and not less restricted. I may be
misunderstanding what you mean by this though...

-David

On May 16, 2009, at 6:28 PM, Adrian Crum wrote:

>
> The idea I had in mind was having the ability to assign a filter to
> an entity for access control scenario 3 - http://docs.ofbiz.org/x/
> JR8. If a user isn't logged in then there is no filter assigned to
> the entity, so it operates normally.
>
> Btw, I'm not going to write any code until we get all of the details
> worked out and finalize the design.
>
> -Adrian
>
> --- On Sat, 5/16/09, David E Jones <[hidden email]>
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Brainstorming: Security Requirements/Scenarios
>> To: [hidden email]
>> Date: Saturday, May 16, 2009, 4:14 PM
>>
>> Sorry for not getting back to this sooner. I spent a little
>> too much time on it earlier this week and then got a bit
>> slammed with other things...
>>
>> I'm glad we're discussing this and not doing any of it
>> yet... there are some possibly big issues.
>>
>> The main one that concerns me is this question: what do
>> permissions on entities mean? If you don't have the
>> permission, are allowed to do anything with the entity? If
>> you are not logged in, what is allowed and what isn't? Do we
>> allow code to circumvent the entity security by explicitly
>> using a non-secure delegator object (which would be the
>> default if we allow any sort of extension to it to be
>> optional)? What about cases where there are multiple
>> delegators involved?
>>
>> Anyway, it all comes down to this: if we don't have
>> something in place for mandatory, always-on entity security,
>> then why have any at all? It would be too easy to just
>> circumvent the security by not having a user passed down, or
>> by not going through the access controlled delegator... and
>> it's even worse if we have to change existing to get it to
>> do that because then it's not just malicious code that gets
>> through this way, it is also any code that we (or anybody
>> with custom code) misses when migrating. I'd rather have a
>> design that eliminates or at least mitigates that risk.
>>
>> About the dependency issue, I'm not too worried about it...
>> that's just a matter of refactoring existing code, and no
>> matter how we support entity-level security some refactoring
>> and reorganizing of code will be necessary.
>>
>> Anyway, I like the ThreadLocal ExecutionContext because it
>> can be a lower level object used for common information, and
>> it can be setup to just always be there, and if there are
>> multiple delegator instances used by a certain code block
>> they will all see the same ExecutionContext. Of course, with
>> that approach we still have decide how the system should
>> behave if no user is logged in... I suppose we simply hope
>> that a service or something else has run that the
>> anonymous/non-user is allowed to access and that it has
>> inherited permissions for things it calls... otherwise the
>> non-user will probably never have permission to touch an
>> entity.
>>
>> One thing that crossed my mind with all of this, BTW, is
>> that maybe we should just not worry about the entity
>> security for now. We can implement it for other artifacts
>> and worry about the entity ones later on without affecting
>> the other stuff...
>>
>> -David
>>
>>
>> On May 16, 2009, at 1:43 PM, Adrian Crum wrote:
>>
>>>
>>> I spent some time researching the GenericDelegator. I
>> think I have come up with a solution.
>>>
>>> First off, there are more than 2,000 references to
>> GenericDelegator in the project. I'm sure there are many
>> installations that have customizations that reference
>> GenericDelegator also. Changing the GenericDelegator API to
>> accommodate the new security design is not a good idea - it
>> would break a lot of code.
>>>
>>> There is also an issue with cross-dependency. Any
>> attempt to put security-related code in the GenericDelegator
>> will fail because the security component is built after the
>> entity component.
>>>
>>> If we changed GenericDelegator so that we can make
>> per-thread instances of it, then the class could be extended
>> to add the new design functionality. All existing code would
>> still reference GenericDelegator, but it will actually be an
>> extended version that is security-aware.
>>>
>>> I spent some time separating GenericDelegator's data
>> out and put it in a separate class called DelegatorData.
>> There is only one instance of DelegatorData per delegator
>> name. GenericDelegator holds a reference to a DelegatorData
>> instance, so everything still works the same. Now we can
>> have more than one instance of GenericDelegator.
>>>
>>> We could extend GenericDelegator in the entityext
>> component to make it security-aware. That would eliminate
>> any cross-dependency issues. The dispatch context, request
>> handler, etc would create instances of the extended
>> GenericDelegator.
>>>
>>> What do you think?
>>>
>>> -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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

A common request that appears on the mailing list is the ability to filter records depending on the user. Let's say a salesperson can only see customers they are assigned to. Currently, you can filter on Party Role so the salesperson gets a list of customers, but that won't restrict the list to only that salesperson's customers.

A filter could be created that filters out customers related to the salesperson, and that filter could be assigned to the Party entity in the salesperson's permissions.

If the salesperson isn't logged in, then they aren't going to see anything anyway.

-Adrian

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

> From: David E Jones <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> Date: Sunday, May 17, 2009, 1:26 AM
>
> Isn't that the opposite of what we want? Things should be
> more
> restricted if there is no user, and not less restricted. I
> may be
> misunderstanding what you mean by this though...
>
> -David
>
>
> On May 16, 2009, at 6:28 PM, Adrian Crum wrote:
>
> >
> > The idea I had in mind was having the ability to
> assign a filter to
> > an entity for access control scenario 3 - http://docs.ofbiz.org/x/
> > JR8. If a user isn't logged in then there is no filter
> assigned to
> > the entity, so it operates normally.
> >
> > Btw, I'm not going to write any code until we get all
> of the details
> > worked out and finalize the design.
> >
> > -Adrian
> >
> > --- On Sat, 5/16/09, David E Jones <[hidden email]>
>
> > wrote:
> >
> >> From: David E Jones <[hidden email]>
> >> Subject: Re: Brainstorming: Security
> Requirements/Scenarios
> >> To: [hidden email]
> >> Date: Saturday, May 16, 2009, 4:14 PM
> >>
> >> Sorry for not getting back to this sooner. I spent
> a little
> >> too much time on it earlier this week and then got
> a bit
> >> slammed with other things...
> >>
> >> I'm glad we're discussing this and not doing any
> of it
> >> yet... there are some possibly big issues.
> >>
> >> The main one that concerns me is this question:
> what do
> >> permissions on entities mean? If you don't have
> the
> >> permission, are allowed to do anything with the
> entity? If
> >> you are not logged in, what is allowed and what
> isn't? Do we
> >> allow code to circumvent the entity security by
> explicitly
> >> using a non-secure delegator object (which would
> be the
> >> default if we allow any sort of extension to it to
> be
> >> optional)? What about cases where there are
> multiple
> >> delegators involved?
> >>
> >> Anyway, it all comes down to this: if we don't
> have
> >> something in place for mandatory, always-on entity
> security,
> >> then why have any at all? It would be too easy to
> just
> >> circumvent the security by not having a user
> passed down, or
> >> by not going through the access controlled
> delegator... and
> >> it's even worse if we have to change existing to
> get it to
> >> do that because then it's not just malicious code
> that gets
> >> through this way, it is also any code that we (or
> anybody
> >> with custom code) misses when migrating. I'd
> rather have a
> >> design that eliminates or at least mitigates that
> risk.
> >>
> >> About the dependency issue, I'm not too worried
> about it...
> >> that's just a matter of refactoring existing code,
> and no
> >> matter how we support entity-level security some
> refactoring
> >> and reorganizing of code will be necessary.
> >>
> >> Anyway, I like the ThreadLocal ExecutionContext
> because it
> >> can be a lower level object used for common
> information, and
> >> it can be setup to just always be there, and if
> there are
> >> multiple delegator instances used by a certain
> code block
> >> they will all see the same ExecutionContext. Of
> course, with
> >> that approach we still have decide how the system
> should
> >> behave if no user is logged in... I suppose we
> simply hope
> >> that a service or something else has run that the
> >> anonymous/non-user is allowed to access and that
> it has
> >> inherited permissions for things it calls...
> otherwise the
> >> non-user will probably never have permission to
> touch an
> >> entity.
> >>
> >> One thing that crossed my mind with all of this,
> BTW, is
> >> that maybe we should just not worry about the
> entity
> >> security for now. We can implement it for other
> artifacts
> >> and worry about the entity ones later on without
> affecting
> >> the other stuff...
> >>
> >> -David
> >>
> >>
> >> On May 16, 2009, at 1:43 PM, Adrian Crum wrote:
> >>
> >>>
> >>> I spent some time researching the
> GenericDelegator. I
> >> think I have come up with a solution.
> >>>
> >>> First off, there are more than 2,000
> references to
> >> GenericDelegator in the project. I'm sure there
> are many
> >> installations that have customizations that
> reference
> >> GenericDelegator also. Changing the
> GenericDelegator API to
> >> accommodate the new security design is not a good
> idea - it
> >> would break a lot of code.
> >>>
> >>> There is also an issue with cross-dependency.
> Any
> >> attempt to put security-related code in the
> GenericDelegator
> >> will fail because the security component is built
> after the
> >> entity component.
> >>>
> >>> If we changed GenericDelegator so that we can
> make
> >> per-thread instances of it, then the class could
> be extended
> >> to add the new design functionality. All existing
> code would
> >> still reference GenericDelegator, but it will
> actually be an
> >> extended version that is security-aware.
> >>>
> >>> I spent some time separating
> GenericDelegator's data
> >> out and put it in a separate class called
> DelegatorData.
> >> There is only one instance of DelegatorData per
> delegator
> >> name. GenericDelegator holds a reference to a
> DelegatorData
> >> instance, so everything still works the same. Now
> we can
> >> have more than one instance of GenericDelegator.
> >>>
> >>> We could extend GenericDelegator in the
> entityext
> >> component to make it security-aware. That would
> eliminate
> >> any cross-dependency issues. The dispatch context,
> request
> >> handler, etc would create instances of the
> extended
> >> GenericDelegator.
> >>>
> >>> What do you think?
> >>>
> >>> -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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

ExecutionContext is just a means of keeping track of the program flow - it doesn't include security.

-Adrian

--- On Sat, 5/16/09, Harmeet Bedi <[hidden email]> wrote:

> From: Harmeet Bedi <[hidden email]>
> Subject: Re: Brainstorming: Security Requirements/Scenarios
> To: [hidden email]
> Date: Saturday, May 16, 2009, 3:40 PM
> Wondering what would the API
> extension to GenericDelegator or DelegatorInterface look
> like.. is it [get|set]ExecutionContext() or more ?
>
> > Any attempt to put security-related code in the
> GenericDelegator will fail because the security component is
> built after the entity component.
>
> perhaps this could be addressed by making ExecutionContext
> an interface in entity component with implementation
> injected on use by followon component.
>
> Harmeet
>
> ----- Original Message -----
> From: "Adrian Crum" <[hidden email]>
> To: [hidden email]
> Sent: Saturday, May 16, 2009 3:43:13 PM GMT -05:00
> US/Canada Eastern
> Subject: Re: Brainstorming: Security
> Requirements/Scenarios
>
>
> I spent some time researching the GenericDelegator. I think
> I have come up with a solution.
>
> First off, there are more than 2,000 references to
> GenericDelegator in the project. I'm sure there are many
> installations that have customizations that reference
> GenericDelegator also. Changing the GenericDelegator API to
> accommodate the new security design is not a good idea - it
> would break a lot of code.
>
> There is also an issue with cross-dependency. Any attempt
> to put security-related code in the GenericDelegator will
> fail because the security component is built after the
> entity component.
>
> If we changed GenericDelegator so that we can make
> per-thread instances of it, then the class could be extended
> to add the new design functionality. All existing code would
> still reference GenericDelegator, but it will actually be an
> extended version that is security-aware.
>
> I spent some time separating GenericDelegator's data out
> and put it in a separate class called DelegatorData. There
> is only one instance of DelegatorData per delegator name.
> GenericDelegator holds a reference to a DelegatorData
> instance, so everything still works the same. Now we can
> have more than one instance of GenericDelegator.
>
> We could extend GenericDelegator in the entityext component
> to make it security-aware. That would eliminate any
> cross-dependency issues. The dispatch context, request
> handler, etc would create instances of the extended
> GenericDelegator.
>
> What do you think?
>
> -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
> > >>>>>
> > >>>>
> > >>>
> >
> >
>
>
>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by Adrian Crum-2

On May 17, 2009, at 7:32 AM, Adrian Crum wrote:

> A common request that appears on the mailing list is the ability to
> filter records depending on the user. Let's say a salesperson can
> only see customers they are assigned to. Currently, you can filter
> on Party Role so the salesperson gets a list of customers, but that
> won't restrict the list to only that salesperson's customers.
>
> A filter could be created that filters out customers related to the
> salesperson, and that filter could be assigned to the Party entity
> in the salesperson's permissions.

Currently authentication in OFBiz is done in 2 very distinct ways, and
I often talk about the distinction with the terms artifact-level and
record-level permissions.

If I understand correctly what you are describing above it is simply
record level permissions. And yes, I agree that is a common
requirement that we've discussed quite a bit. I'm worried I'm
misunderstanding though because I'm not sure how that fits with
comment...

> If the salesperson isn't logged in, then they aren't going to see
> anything anyway.

Yes, probably true for a salesperson... but what about an ecommerce
customer or other cases where they probably won't have any explicit
permissions, just implicit authorization based on a direct record-
level connection (ie any user can change their own contact info type
of rule that is currently implemented in code)? In those cases there
may be no user passed down, or it may be a dummy user like the
"anonymous" user, but they still need to perform various operations.

-David

> --- On Sun, 5/17/09, David E Jones <[hidden email]>
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Brainstorming: Security Requirements/Scenarios
>> To: [hidden email]
>> Date: Sunday, May 17, 2009, 1:26 AM
>>
>> Isn't that the opposite of what we want? Things should be
>> more
>> restricted if there is no user, and not less restricted. I
>> may be
>> misunderstanding what you mean by this though...
>>
>> -David
>>
>>
>> On May 16, 2009, at 6:28 PM, Adrian Crum wrote:
>>
>>>
>>> The idea I had in mind was having the ability to
>> assign a filter to
>>> an entity for access control scenario 3 - http://docs.ofbiz.org/x/
>>> JR8. If a user isn't logged in then there is no filter
>> assigned to
>>> the entity, so it operates normally.
>>>
>>> Btw, I'm not going to write any code until we get all
>> of the details
>>> worked out and finalize the design.
>>>
>>> -Adrian
>>>
>>> --- On Sat, 5/16/09, David E Jones <[hidden email]>
>>
>>> wrote:
>>>
>>>> From: David E Jones <[hidden email]>
>>>> Subject: Re: Brainstorming: Security
>> Requirements/Scenarios
>>>> To: [hidden email]
>>>> Date: Saturday, May 16, 2009, 4:14 PM
>>>>
>>>> Sorry for not getting back to this sooner. I spent
>> a little
>>>> too much time on it earlier this week and then got
>> a bit
>>>> slammed with other things...
>>>>
>>>> I'm glad we're discussing this and not doing any
>> of it
>>>> yet... there are some possibly big issues.
>>>>
>>>> The main one that concerns me is this question:
>> what do
>>>> permissions on entities mean? If you don't have
>> the
>>>> permission, are allowed to do anything with the
>> entity? If
>>>> you are not logged in, what is allowed and what
>> isn't? Do we
>>>> allow code to circumvent the entity security by
>> explicitly
>>>> using a non-secure delegator object (which would
>> be the
>>>> default if we allow any sort of extension to it to
>> be
>>>> optional)? What about cases where there are
>> multiple
>>>> delegators involved?
>>>>
>>>> Anyway, it all comes down to this: if we don't
>> have
>>>> something in place for mandatory, always-on entity
>> security,
>>>> then why have any at all? It would be too easy to
>> just
>>>> circumvent the security by not having a user
>> passed down, or
>>>> by not going through the access controlled
>> delegator... and
>>>> it's even worse if we have to change existing to
>> get it to
>>>> do that because then it's not just malicious code
>> that gets
>>>> through this way, it is also any code that we (or
>> anybody
>>>> with custom code) misses when migrating. I'd
>> rather have a
>>>> design that eliminates or at least mitigates that
>> risk.
>>>>
>>>> About the dependency issue, I'm not too worried
>> about it...
>>>> that's just a matter of refactoring existing code,
>> and no
>>>> matter how we support entity-level security some
>> refactoring
>>>> and reorganizing of code will be necessary.
>>>>
>>>> Anyway, I like the ThreadLocal ExecutionContext
>> because it
>>>> can be a lower level object used for common
>> information, and
>>>> it can be setup to just always be there, and if
>> there are
>>>> multiple delegator instances used by a certain
>> code block
>>>> they will all see the same ExecutionContext. Of
>> course, with
>>>> that approach we still have decide how the system
>> should
>>>> behave if no user is logged in... I suppose we
>> simply hope
>>>> that a service or something else has run that the
>>>> anonymous/non-user is allowed to access and that
>> it has
>>>> inherited permissions for things it calls...
>> otherwise the
>>>> non-user will probably never have permission to
>> touch an
>>>> entity.
>>>>
>>>> One thing that crossed my mind with all of this,
>> BTW, is
>>>> that maybe we should just not worry about the
>> entity
>>>> security for now. We can implement it for other
>> artifacts
>>>> and worry about the entity ones later on without
>> affecting
>>>> the other stuff...
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 16, 2009, at 1:43 PM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> I spent some time researching the
>> GenericDelegator. I
>>>> think I have come up with a solution.
>>>>>
>>>>> First off, there are more than 2,000
>> references to
>>>> GenericDelegator in the project. I'm sure there
>> are many
>>>> installations that have customizations that
>> reference
>>>> GenericDelegator also. Changing the
>> GenericDelegator API to
>>>> accommodate the new security design is not a good
>> idea - it
>>>> would break a lot of code.
>>>>>
>>>>> There is also an issue with cross-dependency.
>> Any
>>>> attempt to put security-related code in the
>> GenericDelegator
>>>> will fail because the security component is built
>> after the
>>>> entity component.
>>>>>
>>>>> If we changed GenericDelegator so that we can
>> make
>>>> per-thread instances of it, then the class could
>> be extended
>>>> to add the new design functionality. All existing
>> code would
>>>> still reference GenericDelegator, but it will
>> actually be an
>>>> extended version that is security-aware.
>>>>>
>>>>> I spent some time separating
>> GenericDelegator's data
>>>> out and put it in a separate class called
>> DelegatorData.
>>>> There is only one instance of DelegatorData per
>> delegator
>>>> name. GenericDelegator holds a reference to a
>> DelegatorData
>>>> instance, so everything still works the same. Now
>> we can
>>>> have more than one instance of GenericDelegator.
>>>>>
>>>>> We could extend GenericDelegator in the
>> entityext
>>>> component to make it security-aware. That would
>> eliminate
>>>> any cross-dependency issues. The dispatch context,
>> request
>>>> handler, etc would create instances of the
>> extended
>>>> GenericDelegator.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

--- On Sun, 5/17/09, David E Jones <[hidden email]> wrote:
> If I understand correctly what you are describing above it
> is simply
> record level permissions. And yes, I agree that is a
> common
> requirement that we've discussed quite a bit. I'm worried
> I'm
> misunderstanding though because I'm not sure how that fits
> with
> comment...

It fits into the design objective because it takes the record-level filtering out of code and puts it in assigned permissions. Isn't that one of the objectives? Remove the security checking that is embedded in code and put it in the database where an administrator can assign it to a user.

Instead of hard-coding record-level permission checking inside some other service, extract the record-level permission checking code, make it a service, and assign the service as part of a user's permissions.

It's clear we have disconnected somewhere. The existing entity engine doesn't know about security. It works with not-logged-in users and anonymous users and whatever else comes along. I'm not suggesting we change any of that. Keep it all the same. But add the ability to restrict records based on the user. If there is no user, then it does what it has always done. I don't know how else I can say it. *shrug*

-Adrian

BJ Freeman

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

as a devils advocate here I don't see any mention of hackers, after all
this is security. for instance I think it is harder to override security
built into the code than security external like a database.
A database can be compromised and there goes your security.

Adrian Crum sent the following on 5/17/2009 10:04 PM:

> --- On Sun, 5/17/09, David E Jones <[hidden email]> wrote:
>> If I understand correctly what you are describing above it
>> is simply
>> record level permissions. And yes, I agree that is a
>> common
>> requirement that we've discussed quite a bit. I'm worried
>> I'm
>> misunderstanding though because I'm not sure how that fits
>> with
>> comment...
>
> It fits into the design objective because it takes the record-level filtering out of code and puts it in assigned permissions. Isn't that one of the objectives? Remove the security checking that is embedded in code and put it in the database where an administrator can assign it to a user.
>
> Instead of hard-coding record-level permission checking inside some other service, extract the record-level permission checking code, make it a service, and assign the service as part of a user's permissions.
>
> It's clear we have disconnected somewhere. The existing entity engine doesn't know about security. It works with not-logged-in users and anonymous users and whatever else comes along. I'm not suggesting we change any of that. Keep it all the same. But add the ability to restrict records based on the user. If there is no user, then it does what it has always done. I don't know how else I can say it. *shrug*
>
> -Adrian
>
>
>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

If a hacker gained access to the database in the existing design, the
same would be true.

-Adrian

BJ Freeman wrote:

> as a devils advocate here I don't see any mention of hackers, after all
> this is security. for instance I think it is harder to override security
> built into the code than security external like a database.
> A database can be compromised and there goes your security.
>
>
> Adrian Crum sent the following on 5/17/2009 10:04 PM:
>> --- On Sun, 5/17/09, David E Jones <[hidden email]> wrote:
>>> If I understand correctly what you are describing above it
>>> is simply
>>> record level permissions. And yes, I agree that is a
>>> common
>>> requirement that we've discussed quite a bit. I'm worried
>>> I'm
>>> misunderstanding though because I'm not sure how that fits
>>> with
>>> comment...
>> It fits into the design objective because it takes the record-level filtering out of code and puts it in assigned permissions. Isn't that one of the objectives? Remove the security checking that is embedded in code and put it in the database where an administrator can assign it to a user.
>>
>> Instead of hard-coding record-level permission checking inside some other service, extract the record-level permission checking code, make it a service, and assign the service as part of a user's permissions.
>>
>> It's clear we have disconnected somewhere. The existing entity engine doesn't know about security. It works with not-logged-in users and anonymous users and whatever else comes along. I'm not suggesting we change any of that. Keep it all the same. But add the ability to restrict records based on the user. If there is no user, then it does what it has always done. I don't know how else I can say it. *shrug*
>>
>> -Adrian
>>
>>
>>
>>
>>
>

David E Jones-3

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by BJ Freeman

Isn't that a little bit backwards?

Usually the app server is on the front line and is compromised first,
especially since usually the app server talks to the database server
on an internal network and the database server isn't available
externally.

Also, protecting the programs on the app server is usually not a big
deal, it's protecting the data that is the whole point as this is
where all company and customer data is located. In other words, if
they make it to the data having access to permissions is the least of
our concerns since they could play with financial data and such...

-David

On May 18, 2009, at 12:28 PM, BJ Freeman wrote:

> as a devils advocate here I don't see any mention of hackers, after
> all
> this is security. for instance I think it is harder to override
> security
> built into the code than security external like a database.
> A database can be compromised and there goes your security.
>
>
> Adrian Crum sent the following on 5/17/2009 10:04 PM:
>> --- On Sun, 5/17/09, David E Jones <[hidden email]>
>> wrote:
>>> If I understand correctly what you are describing above it
>>> is simply
>>> record level permissions. And yes, I agree that is a
>>> common
>>> requirement that we've discussed quite a bit. I'm worried
>>> I'm
>>> misunderstanding though because I'm not sure how that fits
>>> with
>>> comment...
>>
>> It fits into the design objective because it takes the record-level
>> filtering out of code and puts it in assigned permissions. Isn't
>> that one of the objectives? Remove the security checking that is
>> embedded in code and put it in the database where an administrator
>> can assign it to a user.
>>
>> Instead of hard-coding record-level permission checking inside some
>> other service, extract the record-level permission checking code,
>> make it a service, and assign the service as part of a user's
>> permissions.
>>
>> It's clear we have disconnected somewhere. The existing entity
>> engine doesn't know about security. It works with not-logged-in
>> users and anonymous users and whatever else comes along. I'm not
>> suggesting we change any of that. Keep it all the same. But add the
>> ability to restrict records based on the user. If there is no user,
>> then it does what it has always done. I don't know how else I can
>> say it. *shrug*
>>
>> -Adrian
>>
>>
>>
>>
>>
>
> --
> BJ Freeman
> http://www.businessesnetwork.com/automation
> http://bjfreeman.elance.com
> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
> Systems Integrator.
>

Adrian Crum

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by Adrian Crum-2

I'm bumping this because I would like to begin working on it.

I've been updating the design document when I have time -
http://docs.ofbiz.org/x/Ch8.

There are two design issues that I would like to get finalized soon, so
that work can begin:

1. The document proposes converting the Security abstract class to an
interface, and adding new methods to the interface that will implement
the new security design. If there are no objections to changing Security
to an interface, then I will design and document the new Security API.

2. The document describes two artifact hierarchies - static and dynamic.
The pros and cons of each is demonstrated in the Access Control
Scenarios portion of the document. We need to decide which approach to
use. Once that decision is made, we can build out more of the design.

-Adrian

Adrian Crum wrote:

David E. Jones-2

Re: Brainstorming: Security Requirements/Scenarios

On Jul 9, 2009, at 9:40 AM, Adrian Crum wrote:

> I'm bumping this because I would like to begin working on it.
>
> I've been updating the design document when I have time - http://docs.ofbiz.org/x/Ch8
> .
>
> There are two design issues that I would like to get finalized soon,
> so that work can begin:
>
> 1. The document proposes converting the Security abstract class to
> an interface, and adding new methods to the interface that will
> implement the new security design. If there are no objections to
> changing Security to an interface, then I will design and document
> the new Security API.

What would go in the new security API? Isn't the idea to externalize
this and make it configurable?

> 2. The document describes two artifact hierarchies - static and
> dynamic. The pros and cons of each is demonstrated in the Access
> Control Scenarios portion of the document. We need to decide which
> approach to use. Once that decision is made, we can build out more
> of the design.

In the examples you've done for static and dynamic I don't think the
dynamic ones really show how it is meant to be used. What I mean by
that is that the point of the dynamic ones is that the "path" as it
were doesn't depend at all on where the artifact is located, it only
depends on how the artifact is referred to or "invoked" at run time.

In fact, to be frank, I don't think there is any reason we should
consider not using the "dynamic" method. There are a couple of big
problems I see with the current security, or the most common complaints:

1. you have to modify "code" (usually XML files) to change how
permissions are used and which are available

2. the current permissions checking at runtime limits reuse of
artifacts because the permissions are often determined by artifact and
you can't change the permission (implicitly or explicitly) when the
artifact is used in another application that has a different security
setup (and/or you don't want to give users permissions to the base
applications)

The solutions to these are:

1. configure permissions in the database and not directly in
artifacts, or even in configuration files independent of artifacts

2. use the "dynamic" way of determining the context for an artifact
instead of using where it is located for the context

BTW, to do this one thing that will need to be done is to implement
the "ExecutionContext" object, and on that note I think that will help
with the multi-tenancy and deployment flexibility things that have
been discussed on the list recently (especially by Marc and Henning).
The idea is that nothing would keep a local reference to the delegator
or dispatcher, not even the service engine, control servlet, and other
framework components too.

-David

> Adrian Crum wrote:
>> --- On Sun, 5/17/09, David E Jones <[hidden email]>
>> wrote:
>>> If I understand correctly what you are describing above it
>>> is simply record level permissions. And yes, I agree that is a
>>> common requirement that we've discussed quite a bit. I'm worried
>>> I'm misunderstanding though because I'm not sure how that fits
>>> with comment...
>> It fits into the design objective because it takes the record-level
>> filtering out of code and puts it in assigned permissions. Isn't
>> that one of the objectives? Remove the security checking that is
>> embedded in code and put it in the database where an administrator
>> can assign it to a user.
>> Instead of hard-coding record-level permission checking inside some
>> other service, extract the record-level permission checking code,
>> make it a service, and assign the service as part of a user's
>> permissions.
>> It's clear we have disconnected somewhere. The existing entity
>> engine doesn't know about security. It works with not-logged-in
>> users and anonymous users and whatever else comes along. I'm not
>> suggesting we change any of that. Keep it all the same. But add the
>> ability to restrict records based on the user. If there is no user,
>> then it does what it has always done. I don't know how else I can
>> say it. *shrug*
>> -Adrian
>>

Adrian Crum-2

Re: Brainstorming: Security Requirements/Scenarios

In reply to this post by David E Jones-3

--- On Thu, 7/9/09, David E Jones <[hidden email]> wrote:
> > 1. The document proposes converting the Security
> abstract class to an interface, and adding new methods to
> the interface that will implement the new security design.
> If there are no objections to changing Security to an
> interface, then I will design and document the new Security
> API.
>
> What would go in the new security API? Isn't the idea to
> externalize this and make it configurable?

One of Andrew's goals was to make the OFBiz security implementation more compatible with third party authorization software - a goal I am 100% in agreement with. I was picturing (and I thought I made this clear in the document, but maybe it needs more work) having a Java interface with a set of methods that would define a security API. The artifacts would interact with that API. The idea is to decouple the implementation of security. The interface's implementation might use OFBiz entities, or Andrew's Cloud, or LDAP. The artifacts won't know the difference - they only see the API.

Artifact <--> Authorization Manager API <--> ???

> > 2. The document describes two artifact hierarchies -
> static and dynamic. The pros and cons of each is
> demonstrated in the Access Control Scenarios portion of the
> document. We need to decide which approach to use. Once that
> decision is made, we can build out more of the design.
>
> In the examples you've done for static and dynamic I don't
> think the dynamic ones really show how it is meant to be
> used.

I agree. I'm not understanding what you have pictured, and I mentioned that in an email and asked if you could update the scenario detail to be more accurate.

> What I mean by that is that the point of the dynamic
> ones is that the "path" as it were doesn't depend at all on
> where the artifact is located, it only depends on how the
> artifact is referred to or "invoked" at run time.
>
> In fact, to be frank, I don't think there is any reason we
> should consider not using the "dynamic" method.

The reason I see a problem with that approach (and I'm not trying to be argumentative, just trying to make sure we understand each other's concepts) is there could be hundreds of execution paths leading to an artifact. Each of those execution paths would have to have permissions assigned to them.

In the static hierarchy, the Authorization Manager doesn't care how you got to an artifact, it only cares about what your permissions are once you get there.

> There are a
> couple of big problems I see with the current security, or
> the most common complaints:
>
> 1. you have to modify "code" (usually XML files) to change
> how permissions are used and which are available
>
> 2. the current permissions checking at runtime limits reuse
> of artifacts because the permissions are often determined by
> artifact and you can't change the permission (implicitly or
> explicitly) when the artifact is used in another application
> that has a different security setup (and/or you don't want
> to give users permissions to the base applications)

I agree with both of those. That's why we're having this discussion. :-)

> The solutions to these are:
>
> 1. configure permissions in the database and not directly
> in artifacts, or even in configuration files independent of
> artifacts

Agreed.

> 2. use the "dynamic" way of determining the context for an
> artifact instead of using where it is located for the
> context

Again, I must be missing something. It seems to me this will make things more complicated than they need to be.

> BTW, to do this one thing that will need to be done is to
> implement the "ExecutionContext" object, and on that note I
> think that will help with the multi-tenancy and deployment
> flexibility things that have been discussed on the list
> recently (especially by Marc and Henning). The idea is that
> nothing would keep a local reference to the delegator or
> dispatcher, not even the service engine, control servlet,
> and other framework components too.

Now that I have written a servlet for the iCalendar integration, I know exactly what you're saying here. And I agree 100%. Even if we made that change without the security redesign, it would be a huge plus for the framework.

I know you're really busy, but I think it would really help me (and possibly others) understand your vision of the security redesign if you could improve the access scenario detail pages by fleshing out the dynamic hierarchy part.

Thanks for the reply and comments!

Just so there is no misunderstanding, I'm not going to rush off and start doing anything until it is settled on the mailing list, and marked as finalized on the design document.

-Adrian

David E. Jones-2

Re: Brainstorming: Security Requirements/Scenarios

On Jul 9, 2009, at 9:36 PM, Adrian Crum wrote:

>
> --- On Thu, 7/9/09, David E Jones <[hidden email]> wrote:
>>> 1. The document proposes converting the Security
>> abstract class to an interface, and adding new methods to
>> the interface that will implement the new security design.
>> If there are no objections to changing Security to an
>> interface, then I will design and document the new Security
>> API.
>>
>> What would go in the new security API? Isn't the idea to
>> externalize this and make it configurable?
>
> One of Andrew's goals was to make the OFBiz security implementation
> more compatible with third party authorization software - a goal I
> am 100% in agreement with. I was picturing (and I thought I made
> this clear in the document, but maybe it needs more work) having a
> Java interface with a set of methods that would define a security
> API. The artifacts would interact with that API. The idea is to
> decouple the implementation of security. The interface's
> implementation might use OFBiz entities, or Andrew's Cloud, or LDAP.
> The artifacts won't know the difference - they only see the API.
>
> Artifact <--> Authorization Manager API <--> ???

You're talking about authorization and not authentication, right? Are
there any standards for authorization that we could implement to? (I'm
not aware of any...)

>> What I mean by that is that the point of the dynamic
>> ones is that the "path" as it were doesn't depend at all on
>> where the artifact is located, it only depends on how the
>> artifact is referred to or "invoked" at run time.
>>
>> In fact, to be frank, I don't think there is any reason we
>> should consider not using the "dynamic" method.
>
> The reason I see a problem with that approach (and I'm not trying to
> be argumentative, just trying to make sure we understand each
> other's concepts) is there could be hundreds of execution paths
> leading to an artifact. Each of those execution paths would have to
> have permissions assigned to them.

I'm not sure if you'd ever want to do that. The general idea is that
you specify permissions for a particular artifact and generally you'd
say it is an "inheritable" permission so that anything the artifact
refers to or calls would inherit the permission and not need one of
its own.

With the stuff I wrote up you wouldn't typically even have permissions
for individual services, and sometimes not even for screens. More
commonly you'd grant permission to a webapp, a decorator screen, etc.
If you want to you could do lower level permissions but most of the
time it simply wouldn't be desired or necessary.

> In the static hierarchy, the Authorization Manager doesn't care how
> you got to an artifact, it only cares about what your permissions
> are once you get there.

For lower level artifacts isn't how we go there more important than
the permissions on the artifact itself? For example, a screen may be
used in more than one application and we probably care more about the
application (or part of that application) that it was rendered in than
we do about that particular screen. If we do care about the particular
screen we'd probably still want different permissions depending on
which application it was rendered in.

>> BTW, to do this one thing that will need to be done is to
>> implement the "ExecutionContext" object, and on that note I
>> think that will help with the multi-tenancy and deployment
>> flexibility things that have been discussed on the list
>> recently (especially by Marc and Henning). The idea is that
>> nothing would keep a local reference to the delegator or
>> dispatcher, not even the service engine, control servlet,
>> and other framework components too.
>
> Now that I have written a servlet for the iCalendar integration, I
> know exactly what you're saying here. And I agree 100%. Even if we
> made that change without the security redesign, it would be a huge
> plus for the framework.

Yeah, one way or another this lower-level object should (and hopefully
soon will!) be implemented. It wouldn't depend on the security changes
and the new security stuff could/would use it.

-David

Andrew Zeneski-4

Re: Brainstorming: Security Requirements/Scenarios

+1 on abstracting the Authorization API.
+1 on dynamic hierarchies

I should have some time to knock out some of this code too, so I am
happy to coordinate with whom ever takes the lead.

Andrew

On Fri, Jul 10, 2009 at 3:03 AM, David E Jones<[hidden email]> wrote:

>
> On Jul 9, 2009, at 9:36 PM, Adrian Crum wrote:
>
>>
>> --- On Thu, 7/9/09, David E Jones <[hidden email]> wrote:
>>>>
>>>> 1. The document proposes converting the Security
>>>
>>> abstract class to an interface, and adding new methods to
>>> the interface that will implement the new security design.
>>> If there are no objections to changing Security to an
>>> interface, then I will design and document the new Security
>>> API.
>>>
>>> What would go in the new security API? Isn't the idea to
>>> externalize this and make it configurable?
>>
>> One of Andrew's goals was to make the OFBiz security implementation more
>> compatible with third party authorization software - a goal I am 100% in
>> agreement with. I was picturing (and I thought I made this clear in the
>> document, but maybe it needs more work) having a Java interface with a set
>> of methods that would define a security API. The artifacts would interact
>> with that API. The idea is to decouple the implementation of security. The
>> interface's implementation might use OFBiz entities, or Andrew's Cloud, or
>> LDAP. The artifacts won't know the difference - they only see the API.
>>
>> Artifact <--> Authorization Manager API <--> ???
>
> You're talking about authorization and not authentication, right? Are there
> any standards for authorization that we could implement to? (I'm not aware
> of any...)
>
>
>>> What I mean by that is that the point of the dynamic
>>> ones is that the "path" as it were doesn't depend at all on
>>> where the artifact is located, it only depends on how the
>>> artifact is referred to or "invoked" at run time.
>>>
>>> In fact, to be frank, I don't think there is any reason we
>>> should consider not using the "dynamic" method.
>>
>> The reason I see a problem with that approach (and I'm not trying to be
>> argumentative, just trying to make sure we understand each other's concepts)
>> is there could be hundreds of execution paths leading to an artifact. Each
>> of those execution paths would have to have permissions assigned to them.
>
> I'm not sure if you'd ever want to do that. The general idea is that you
> specify permissions for a particular artifact and generally you'd say it is
> an "inheritable" permission so that anything the artifact refers to or calls
> would inherit the permission and not need one of its own.
>
> With the stuff I wrote up you wouldn't typically even have permissions for
> individual services, and sometimes not even for screens. More commonly you'd
> grant permission to a webapp, a decorator screen, etc. If you want to you
> could do lower level permissions but most of the time it simply wouldn't be
> desired or necessary.
>
>> In the static hierarchy, the Authorization Manager doesn't care how you
>> got to an artifact, it only cares about what your permissions are once you
>> get there.
>
> For lower level artifacts isn't how we go there more important than the
> permissions on the artifact itself? For example, a screen may be used in
> more than one application and we probably care more about the application
> (or part of that application) that it was rendered in than we do about that
> particular screen. If we do care about the particular screen we'd probably
> still want different permissions depending on which application it was
> rendered in.
>
>
>>> BTW, to do this one thing that will need to be done is to
>>> implement the "ExecutionContext" object, and on that note I
>>> think that will help with the multi-tenancy and deployment
>>> flexibility things that have been discussed on the list
>>> recently (especially by Marc and Henning). The idea is that
>>> nothing would keep a local reference to the delegator or
>>> dispatcher, not even the service engine, control servlet,
>>> and other framework components too.
>>
>> Now that I have written a servlet for the iCalendar integration, I know
>> exactly what you're saying here. And I agree 100%. Even if we made that
>> change without the security redesign, it would be a huge plus for the
>> framework.
>
> Yeah, one way or another this lower-level object should (and hopefully soon
> will!) be implemented. It wouldn't depend on the security changes and the
> new security stuff could/would use it.
>
> -David
>
>
>

David E. Jones-2

Re: Brainstorming: Security Requirements/Scenarios

Cool. I started working on some of the execution context code. Both
this and the security changes look like they'll involve some major
refactoring and wide-spread changes, so I'm planning to get a branch
going. I'll commit what I've done so far soon (hopefully later today).

-David

On Jul 13, 2009, at 10:31 AM, Andrew Zeneski wrote:

> +1 on abstracting the Authorization API.
> +1 on dynamic hierarchies
>
> I should have some time to knock out some of this code too, so I am
> happy to coordinate with whom ever takes the lead.
>
> Andrew
>
> On Fri, Jul 10, 2009 at 3:03 AM, David E Jones<[hidden email]> wrote:
>>
>> On Jul 9, 2009, at 9:36 PM, Adrian Crum wrote:
>>
>>>
>>> --- On Thu, 7/9/09, David E Jones <[hidden email]> wrote:
>>>>>
>>>>> 1. The document proposes converting the Security
>>>>
>>>> abstract class to an interface, and adding new methods to
>>>> the interface that will implement the new security design.
>>>> If there are no objections to changing Security to an
>>>> interface, then I will design and document the new Security
>>>> API.
>>>>
>>>> What would go in the new security API? Isn't the idea to
>>>> externalize this and make it configurable?
>>>
>>> One of Andrew's goals was to make the OFBiz security
>>> implementation more
>>> compatible with third party authorization software - a goal I am
>>> 100% in
>>> agreement with. I was picturing (and I thought I made this clear
>>> in the
>>> document, but maybe it needs more work) having a Java interface
>>> with a set
>>> of methods that would define a security API. The artifacts would
>>> interact
>>> with that API. The idea is to decouple the implementation of
>>> security. The
>>> interface's implementation might use OFBiz entities, or Andrew's
>>> Cloud, or
>>> LDAP. The artifacts won't know the difference - they only see the
>>> API.
>>>
>>> Artifact <--> Authorization Manager API <--> ???
>>
>> You're talking about authorization and not authentication, right?
>> Are there
>> any standards for authorization that we could implement to? (I'm
>> not aware
>> of any...)
>>
>>
>>>> What I mean by that is that the point of the dynamic
>>>> ones is that the "path" as it were doesn't depend at all on
>>>> where the artifact is located, it only depends on how the
>>>> artifact is referred to or "invoked" at run time.
>>>>
>>>> In fact, to be frank, I don't think there is any reason we
>>>> should consider not using the "dynamic" method.
>>>
>>> The reason I see a problem with that approach (and I'm not trying
>>> to be
>>> argumentative, just trying to make sure we understand each other's
>>> concepts)
>>> is there could be hundreds of execution paths leading to an
>>> artifact. Each
>>> of those execution paths would have to have permissions assigned
>>> to them.
>>
>> I'm not sure if you'd ever want to do that. The general idea is
>> that you
>> specify permissions for a particular artifact and generally you'd
>> say it is
>> an "inheritable" permission so that anything the artifact refers to
>> or calls
>> would inherit the permission and not need one of its own.
>>
>> With the stuff I wrote up you wouldn't typically even have
>> permissions for
>> individual services, and sometimes not even for screens. More
>> commonly you'd
>> grant permission to a webapp, a decorator screen, etc. If you want
>> to you
>> could do lower level permissions but most of the time it simply
>> wouldn't be
>> desired or necessary.
>>
>>> In the static hierarchy, the Authorization Manager doesn't care
>>> how you
>>> got to an artifact, it only cares about what your permissions are
>>> once you
>>> get there.
>>
>> For lower level artifacts isn't how we go there more important than
>> the
>> permissions on the artifact itself? For example, a screen may be
>> used in
>> more than one application and we probably care more about the
>> application
>> (or part of that application) that it was rendered in than we do
>> about that
>> particular screen. If we do care about the particular screen we'd
>> probably
>> still want different permissions depending on which application it
>> was
>> rendered in.
>>
>>
>>>> BTW, to do this one thing that will need to be done is to
>>>> implement the "ExecutionContext" object, and on that note I
>>>> think that will help with the multi-tenancy and deployment
>>>> flexibility things that have been discussed on the list
>>>> recently (especially by Marc and Henning). The idea is that
>>>> nothing would keep a local reference to the delegator or
>>>> dispatcher, not even the service engine, control servlet,
>>>> and other framework components too.
>>>
>>> Now that I have written a servlet for the iCalendar integration, I
>>> know
>>> exactly what you're saying here. And I agree 100%. Even if we made
>>> that
>>> change without the security redesign, it would be a huge plus for
>>> the
>>> framework.
>>
>> Yeah, one way or another this lower-level object should (and
>> hopefully soon
>> will!) be implemented. It wouldn't depend on the security changes
>> and the
>> new security stuff could/would use it.
>>
>> -David
>>
>>
>>