Brainstorming: Security Configuration Patterns

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3

Sorry, this message was supposed to go on the other thread  
("Brainstorming: Security Requirements/Scenarios").

Please ignore this, we'll need to do something different for these  
items... :)

-David


On May 10, 2009, at 10:10 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:46 PM, David E Jones wrote:
>
>>
>> There has been a bit of discussion in this thread (and most of it  
>> on topic, so thanks for that), but in reviewing it I can't find any  
>> specific alternatives to add to this list. I'd like to move on to  
>> discussing the merits of these things soon and see which approach  
>> we each like best (or worst!), so if there is anything anyone would  
>> like to add to the list or if anyone has questions about any items  
>> on this list please speak up!
>>
>> -David
>>
>>
>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>
>>>
>>> This thread is specifically for discussing possible configuration  
>>> patterns to use in OFBiz going forward. Please keep other  
>>> discussion in another thread, including the merits of each  
>>> possibility... let's just brainstorm in this thread.
>>>
>>> To get things started, here are the patterns that have been  
>>> discussed recently (in high level terms, we can get into  
>>> implementation and specific practices later on), these are in no  
>>> particular order:
>>>
>>> 1. artifacts responsible for their own security (especially  
>>> services and screens), and security permissions are referred to  
>>> directly (ie the actual permissions are configured directly in the  
>>> XML tags for the artifact)
>>>
>>> 2. artifacts responsible for their own security, and no direct  
>>> references are used and instead an indirect security control is  
>>> referred to; this is basically the permission service model we've  
>>> been using where a permission service is basically a security  
>>> policy that refers to permissions, can query/filter/whatever to do  
>>> record level security, and in customization the permission service  
>>> can be overridden or its function changed by ECA rules without  
>>> touching any OOTB code or configuration
>>>
>>> 3. a hybrid of #1 and #2 where artifacts refer directly to  
>>> permissions and there is external configuration based on those  
>>> permissions that can add other qualifying permissions and/or  
>>> invoke logic to change how that permission is evaluated (ie  
>>> override the default behavior of requiring the user to have that  
>>> permission and either add additional constraints or allow  
>>> alternative constraints even if the user does not have the  
>>> original permission that triggered it all); this is recursive so  
>>> that if an alternative permission is configured that permission  
>>> may also have further alternative permissions; also being  
>>> recursive if attached logic evaluates other permissions that may  
>>> have alternative permissions and/or permission logic attached to  
>>> them; as I understand what Andrew has implemented, this is the  
>>> pattern he followed
>>>
>>> 4. artifacts are not responsible for their own security except to  
>>> specify whether any sort of permission is required or not (ie a  
>>> require-permission attribute, would be true by default; for  
>>> example most ecommerce screens would have this set to false);  
>>> access control would be configured externally so that you can  
>>> configure access at the most granular level possible (we would go  
>>> ALL the way here, including: screens, services, forms, form  
>>> fields, menu items, tree nodes, etc, etc); the access control  
>>> tools would have patterns and features to facilitate grouping of  
>>> artifacts, grouping of users (ie just use the current  
>>> SecurityGroup entity), and support for both functionality access  
>>> and record-level access
>>>
>>> Can anyone thing of other patterns? Again, PLEASE do not comment  
>>> on which one you like better or what you think the advantages or  
>>> disadvantages are of each in this thread (of course, definitely  
>>> think about such things and feel free to comment in other threads,  
>>> I just want this to be a "hat's off" (yes, that is a reference to  
>>> Six Thinking Hats by Edward de Bono; anyone who hasn't read that  
>>> should give it a go!) brainstorming session.
>>>
>>> Thank You!
>>> -David
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3
In reply to this post by David E Jones-3

I haven't seen any additions to this original list in the attempt to  
brainstorm, so I guess we're ready to start discussing the merits of  
each of these approaches.

Please comment!

To get this started I'll express my opinions on the topic. In short,  
#4 is cool and 1-3 are crap. Is that biased enough for you? Well,  
here's why I say that. Right now in order to configure permissions and  
introduce more granular permissions as needed you have to edit some  
sort of XML files (or in some case Java files or other things)  
possibly including screen defs, service defs, and service  
implementations. The most important part of point #4 is that  
authorization settings will be totally external to these artifacts. In  
other words, the authorization settings will refer to the various  
artifacts instead of the artifacts pointing to the authorization  
settings.

IMO that's the most important point: if security can't be configured  
by an end-user and through run-time evaluated data (preferably in the  
database so multiple app servers stay consistent, etc), then what's  
the point? The security config in OFBiz would still be a large,  
expensive, PITA.

That said, other biased comments are now needed to balance the bias I  
just threw into this... ;)

-David


On May 4, 2009, at 11:53 AM, David E Jones wrote:

>
> This thread is specifically for discussing possible configuration  
> patterns to use in OFBiz going forward. Please keep other discussion  
> in another thread, including the merits of each possibility... let's  
> just brainstorm in this thread.
>
> To get things started, here are the patterns that have been  
> discussed recently (in high level terms, we can get into  
> implementation and specific practices later on), these are in no  
> particular order:
>
> 1. artifacts responsible for their own security (especially services  
> and screens), and security permissions are referred to directly (ie  
> the actual permissions are configured directly in the XML tags for  
> the artifact)
>
> 2. artifacts responsible for their own security, and no direct  
> references are used and instead an indirect security control is  
> referred to; this is basically the permission service model we've  
> been using where a permission service is basically a security policy  
> that refers to permissions, can query/filter/whatever to do record  
> level security, and in customization the permission service can be  
> overridden or its function changed by ECA rules without touching any  
> OOTB code or configuration
>
> 3. a hybrid of #1 and #2 where artifacts refer directly to  
> permissions and there is external configuration based on those  
> permissions that can add other qualifying permissions and/or invoke  
> logic to change how that permission is evaluated (ie override the  
> default behavior of requiring the user to have that permission and  
> either add additional constraints or allow alternative constraints  
> even if the user does not have the original permission that  
> triggered it all); this is recursive so that if an alternative  
> permission is configured that permission may also have further  
> alternative permissions; also being recursive if attached logic  
> evaluates other permissions that may have alternative permissions  
> and/or permission logic attached to them; as I understand what  
> Andrew has implemented, this is the pattern he followed
>
> 4. artifacts are not responsible for their own security except to  
> specify whether any sort of permission is required or not (ie a  
> require-permission attribute, would be true by default; for example  
> most ecommerce screens would have this set to false); access control  
> would be configured externally so that you can configure access at  
> the most granular level possible (we would go ALL the way here,  
> including: screens, services, forms, form fields, menu items, tree  
> nodes, etc, etc); the access control tools would have patterns and  
> features to facilitate grouping of artifacts, grouping of users (ie  
> just use the current SecurityGroup entity), and support for both  
> functionality access and record-level access
>
> Can anyone thing of other patterns? Again, PLEASE do not comment on  
> which one you like better or what you think the advantages or  
> disadvantages are of each in this thread (of course, definitely  
> think about such things and feel free to comment in other threads, I  
> just want this to be a "hat's off" (yes, that is a reference to Six  
> Thinking Hats by Edward de Bono; anyone who hasn't read that should  
> give it a go!) brainstorming session.
>
> Thank You!
> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
I'm sure it is no surprise that I like the #4 design the best - I think
it matches the design I proposed.

What IS surprising is the lack of response. We had a lively discussion
on the subject of security design a week ago, and now there doesn't seem
to be much interest in it.

-Adrian


David E Jones wrote:

>
> I haven't seen any additions to this original list in the attempt to
> brainstorm, so I guess we're ready to start discussing the merits of
> each of these approaches.
>
> Please comment!
>
> To get this started I'll express my opinions on the topic. In short, #4
> is cool and 1-3 are crap. Is that biased enough for you? Well, here's
> why I say that. Right now in order to configure permissions and
> introduce more granular permissions as needed you have to edit some sort
> of XML files (or in some case Java files or other things) possibly
> including screen defs, service defs, and service implementations. The
> most important part of point #4 is that authorization settings will be
> totally external to these artifacts. In other words, the authorization
> settings will refer to the various artifacts instead of the artifacts
> pointing to the authorization settings.
>
> IMO that's the most important point: if security can't be configured by
> an end-user and through run-time evaluated data (preferably in the
> database so multiple app servers stay consistent, etc), then what's the
> point? The security config in OFBiz would still be a large, expensive,
> PITA.
>
> That said, other biased comments are now needed to balance the bias I
> just threw into this... ;)
>
> -David
>
>
> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>
>>
>> This thread is specifically for discussing possible configuration
>> patterns to use in OFBiz going forward. Please keep other discussion
>> in another thread, including the merits of each possibility... let's
>> just brainstorm in this thread.
>>
>> To get things started, here are the patterns that have been discussed
>> recently (in high level terms, we can get into implementation and
>> specific practices later on), these are in no particular order:
>>
>> 1. artifacts responsible for their own security (especially services
>> and screens), and security permissions are referred to directly (ie
>> the actual permissions are configured directly in the XML tags for the
>> artifact)
>>
>> 2. artifacts responsible for their own security, and no direct
>> references are used and instead an indirect security control is
>> referred to; this is basically the permission service model we've been
>> using where a permission service is basically a security policy that
>> refers to permissions, can query/filter/whatever to do record level
>> security, and in customization the permission service can be
>> overridden or its function changed by ECA rules without touching any
>> OOTB code or configuration
>>
>> 3. a hybrid of #1 and #2 where artifacts refer directly to permissions
>> and there is external configuration based on those permissions that
>> can add other qualifying permissions and/or invoke logic to change how
>> that permission is evaluated (ie override the default behavior of
>> requiring the user to have that permission and either add additional
>> constraints or allow alternative constraints even if the user does not
>> have the original permission that triggered it all); this is recursive
>> so that if an alternative permission is configured that permission may
>> also have further alternative permissions; also being recursive if
>> attached logic evaluates other permissions that may have alternative
>> permissions and/or permission logic attached to them; as I understand
>> what Andrew has implemented, this is the pattern he followed
>>
>> 4. artifacts are not responsible for their own security except to
>> specify whether any sort of permission is required or not (ie a
>> require-permission attribute, would be true by default; for example
>> most ecommerce screens would have this set to false); access control
>> would be configured externally so that you can configure access at the
>> most granular level possible (we would go ALL the way here, including:
>> screens, services, forms, form fields, menu items, tree nodes, etc,
>> etc); the access control tools would have patterns and features to
>> facilitate grouping of artifacts, grouping of users (ie just use the
>> current SecurityGroup entity), and support for both functionality
>> access and record-level access
>>
>> Can anyone thing of other patterns? Again, PLEASE do not comment on
>> which one you like better or what you think the advantages or
>> disadvantages are of each in this thread (of course, definitely think
>> about such things and feel free to comment in other threads, I just
>> want this to be a "hat's off" (yes, that is a reference to Six
>> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>> give it a go!) brainstorming session.
>>
>> Thank You!
>> -David
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Harmeet Bedi
Thumbs up for option 4.
Silence is agreement and there is lots of it. :-)
If you need any volunteers to do something.. would be happy to contribute.

Harmeet

----- Original Message -----
From: "Adrian Crum" <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 12, 2009 5:21:01 PM GMT -05:00 US/Canada Eastern
Subject: Re: Brainstorming: Security Configuration Patterns

I'm sure it is no surprise that I like the #4 design the best - I think
it matches the design I proposed.

What IS surprising is the lack of response. We had a lively discussion
on the subject of security design a week ago, and now there doesn't seem
to be much interest in it.

-Adrian


David E Jones wrote:

>
> I haven't seen any additions to this original list in the attempt to
> brainstorm, so I guess we're ready to start discussing the merits of
> each of these approaches.
>
> Please comment!
>
> To get this started I'll express my opinions on the topic. In short, #4
> is cool and 1-3 are crap. Is that biased enough for you? Well, here's
> why I say that. Right now in order to configure permissions and
> introduce more granular permissions as needed you have to edit some sort
> of XML files (or in some case Java files or other things) possibly
> including screen defs, service defs, and service implementations. The
> most important part of point #4 is that authorization settings will be
> totally external to these artifacts. In other words, the authorization
> settings will refer to the various artifacts instead of the artifacts
> pointing to the authorization settings.
>
> IMO that's the most important point: if security can't be configured by
> an end-user and through run-time evaluated data (preferably in the
> database so multiple app servers stay consistent, etc), then what's the
> point? The security config in OFBiz would still be a large, expensive,
> PITA.
>
> That said, other biased comments are now needed to balance the bias I
> just threw into this... ;)
>
> -David
>
>
> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>
>>
>> This thread is specifically for discussing possible configuration
>> patterns to use in OFBiz going forward. Please keep other discussion
>> in another thread, including the merits of each possibility... let's
>> just brainstorm in this thread.
>>
>> To get things started, here are the patterns that have been discussed
>> recently (in high level terms, we can get into implementation and
>> specific practices later on), these are in no particular order:
>>
>> 1. artifacts responsible for their own security (especially services
>> and screens), and security permissions are referred to directly (ie
>> the actual permissions are configured directly in the XML tags for the
>> artifact)
>>
>> 2. artifacts responsible for their own security, and no direct
>> references are used and instead an indirect security control is
>> referred to; this is basically the permission service model we've been
>> using where a permission service is basically a security policy that
>> refers to permissions, can query/filter/whatever to do record level
>> security, and in customization the permission service can be
>> overridden or its function changed by ECA rules without touching any
>> OOTB code or configuration
>>
>> 3. a hybrid of #1 and #2 where artifacts refer directly to permissions
>> and there is external configuration based on those permissions that
>> can add other qualifying permissions and/or invoke logic to change how
>> that permission is evaluated (ie override the default behavior of
>> requiring the user to have that permission and either add additional
>> constraints or allow alternative constraints even if the user does not
>> have the original permission that triggered it all); this is recursive
>> so that if an alternative permission is configured that permission may
>> also have further alternative permissions; also being recursive if
>> attached logic evaluates other permissions that may have alternative
>> permissions and/or permission logic attached to them; as I understand
>> what Andrew has implemented, this is the pattern he followed
>>
>> 4. artifacts are not responsible for their own security except to
>> specify whether any sort of permission is required or not (ie a
>> require-permission attribute, would be true by default; for example
>> most ecommerce screens would have this set to false); access control
>> would be configured externally so that you can configure access at the
>> most granular level possible (we would go ALL the way here, including:
>> screens, services, forms, form fields, menu items, tree nodes, etc,
>> etc); the access control tools would have patterns and features to
>> facilitate grouping of artifacts, grouping of users (ie just use the
>> current SecurityGroup entity), and support for both functionality
>> access and record-level access
>>
>> Can anyone thing of other patterns? Again, PLEASE do not comment on
>> which one you like better or what you think the advantages or
>> disadvantages are of each in this thread (of course, definitely think
>> about such things and feel free to comment in other threads, I just
>> want this to be a "hat's off" (yes, that is a reference to Six
>> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>> give it a go!) brainstorming session.
>>
>> Thank You!
>> -David
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Tim Ruppert
In reply to this post by Adrian Crum
+1 - that's what I was saying - let's get back on this horse and make these improvements!  We all know it's sorely needed - don't let discussion stop us from making an impact.

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

o:801.649.6594
f:801.649.6595

----- "Adrian Crum" <[hidden email]> wrote:

> I'm sure it is no surprise that I like the #4 design the best - I
> think
> it matches the design I proposed.
>
> What IS surprising is the lack of response. We had a lively discussion
>
> on the subject of security design a week ago, and now there doesn't
> seem
> to be much interest in it.
>
> -Adrian
>
>
> David E Jones wrote:
> >
> > I haven't seen any additions to this original list in the attempt to
>
> > brainstorm, so I guess we're ready to start discussing the merits of
>
> > each of these approaches.
> >
> > Please comment!
> >
> > To get this started I'll express my opinions on the topic. In short,
> #4
> > is cool and 1-3 are crap. Is that biased enough for you? Well,
> here's
> > why I say that. Right now in order to configure permissions and
> > introduce more granular permissions as needed you have to edit some
> sort
> > of XML files (or in some case Java files or other things) possibly
> > including screen defs, service defs, and service implementations.
> The
> > most important part of point #4 is that authorization settings will
> be
> > totally external to these artifacts. In other words, the
> authorization
> > settings will refer to the various artifacts instead of the
> artifacts
> > pointing to the authorization settings.
> >
> > IMO that's the most important point: if security can't be configured
> by
> > an end-user and through run-time evaluated data (preferably in the
> > database so multiple app servers stay consistent, etc), then what's
> the
> > point? The security config in OFBiz would still be a large,
> expensive,
> > PITA.
> >
> > That said, other biased comments are now needed to balance the bias
> I
> > just threw into this... ;)
> >
> > -David
> >
> >
> > On May 4, 2009, at 11:53 AM, David E Jones wrote:
> >
> >>
> >> This thread is specifically for discussing possible configuration
> >> patterns to use in OFBiz going forward. Please keep other
> discussion
> >> in another thread, including the merits of each possibility...
> let's
> >> just brainstorm in this thread.
> >>
> >> To get things started, here are the patterns that have been
> discussed
> >> recently (in high level terms, we can get into implementation and
> >> specific practices later on), these are in no particular order:
> >>
> >> 1. artifacts responsible for their own security (especially
> services
> >> and screens), and security permissions are referred to directly (ie
>
> >> the actual permissions are configured directly in the XML tags for
> the
> >> artifact)
> >>
> >> 2. artifacts responsible for their own security, and no direct
> >> references are used and instead an indirect security control is
> >> referred to; this is basically the permission service model we've
> been
> >> using where a permission service is basically a security policy
> that
> >> refers to permissions, can query/filter/whatever to do record level
>
> >> security, and in customization the permission service can be
> >> overridden or its function changed by ECA rules without touching
> any
> >> OOTB code or configuration
> >>
> >> 3. a hybrid of #1 and #2 where artifacts refer directly to
> permissions
> >> and there is external configuration based on those permissions that
>
> >> can add other qualifying permissions and/or invoke logic to change
> how
> >> that permission is evaluated (ie override the default behavior of
> >> requiring the user to have that permission and either add
> additional
> >> constraints or allow alternative constraints even if the user does
> not
> >> have the original permission that triggered it all); this is
> recursive
> >> so that if an alternative permission is configured that permission
> may
> >> also have further alternative permissions; also being recursive if
>
> >> attached logic evaluates other permissions that may have
> alternative
> >> permissions and/or permission logic attached to them; as I
> understand
> >> what Andrew has implemented, this is the pattern he followed
> >>
> >> 4. artifacts are not responsible for their own security except to
> >> specify whether any sort of permission is required or not (ie a
> >> require-permission attribute, would be true by default; for example
>
> >> most ecommerce screens would have this set to false); access
> control
> >> would be configured externally so that you can configure access at
> the
> >> most granular level possible (we would go ALL the way here,
> including:
> >> screens, services, forms, form fields, menu items, tree nodes, etc,
>
> >> etc); the access control tools would have patterns and features to
>
> >> facilitate grouping of artifacts, grouping of users (ie just use
> the
> >> current SecurityGroup entity), and support for both functionality
> >> access and record-level access
> >>
> >> Can anyone thing of other patterns? Again, PLEASE do not comment on
>
> >> which one you like better or what you think the advantages or
> >> disadvantages are of each in this thread (of course, definitely
> think
> >> about such things and feel free to comment in other threads, I just
>
> >> want this to be a "hat's off" (yes, that is a reference to Six
> >> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>
> >> give it a go!) brainstorming session.
> >>
> >> Thank You!
> >> -David
> >>
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3

I think the sentiment in the thread is that more feedback would be  
really helpful. It's kind of the lack of discussion that seems to be  
holding this back.

At this point I don't see any comments that argue against item #4, so  
unless someone hops in with comments, issues, or additional  
requirements then we'll just go with that.

The next step, aside from the work that Adrian is doing, is to get the  
data model going for this external configuration of authorization that  
fits for this pattern and the requirements in the other thread.

-David


On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:

> +1 - that's what I was saying - let's get back on this horse and  
> make these improvements!  We all know it's sorely needed - don't let  
> discussion stop us from making an impact.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> ----- "Adrian Crum" <[hidden email]> wrote:
>
>> I'm sure it is no surprise that I like the #4 design the best - I
>> think
>> it matches the design I proposed.
>>
>> What IS surprising is the lack of response. We had a lively  
>> discussion
>>
>> on the subject of security design a week ago, and now there doesn't
>> seem
>> to be much interest in it.
>>
>> -Adrian
>>
>>
>> David E Jones wrote:
>>>
>>> I haven't seen any additions to this original list in the attempt to
>>
>>> brainstorm, so I guess we're ready to start discussing the merits of
>>
>>> each of these approaches.
>>>
>>> Please comment!
>>>
>>> To get this started I'll express my opinions on the topic. In short,
>> #4
>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>> here's
>>> why I say that. Right now in order to configure permissions and
>>> introduce more granular permissions as needed you have to edit some
>> sort
>>> of XML files (or in some case Java files or other things) possibly
>>> including screen defs, service defs, and service implementations.
>> The
>>> most important part of point #4 is that authorization settings will
>> be
>>> totally external to these artifacts. In other words, the
>> authorization
>>> settings will refer to the various artifacts instead of the
>> artifacts
>>> pointing to the authorization settings.
>>>
>>> IMO that's the most important point: if security can't be configured
>> by
>>> an end-user and through run-time evaluated data (preferably in the
>>> database so multiple app servers stay consistent, etc), then what's
>> the
>>> point? The security config in OFBiz would still be a large,
>> expensive,
>>> PITA.
>>>
>>> That said, other biased comments are now needed to balance the bias
>> I
>>> just threw into this... ;)
>>>
>>> -David
>>>
>>>
>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>
>>>>
>>>> This thread is specifically for discussing possible configuration
>>>> patterns to use in OFBiz going forward. Please keep other
>> discussion
>>>> in another thread, including the merits of each possibility...
>> let's
>>>> just brainstorm in this thread.
>>>>
>>>> To get things started, here are the patterns that have been
>> discussed
>>>> recently (in high level terms, we can get into implementation and
>>>> specific practices later on), these are in no particular order:
>>>>
>>>> 1. artifacts responsible for their own security (especially
>> services
>>>> and screens), and security permissions are referred to directly (ie
>>
>>>> the actual permissions are configured directly in the XML tags for
>> the
>>>> artifact)
>>>>
>>>> 2. artifacts responsible for their own security, and no direct
>>>> references are used and instead an indirect security control is
>>>> referred to; this is basically the permission service model we've
>> been
>>>> using where a permission service is basically a security policy
>> that
>>>> refers to permissions, can query/filter/whatever to do record level
>>
>>>> security, and in customization the permission service can be
>>>> overridden or its function changed by ECA rules without touching
>> any
>>>> OOTB code or configuration
>>>>
>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>> permissions
>>>> and there is external configuration based on those permissions that
>>
>>>> can add other qualifying permissions and/or invoke logic to change
>> how
>>>> that permission is evaluated (ie override the default behavior of
>>>> requiring the user to have that permission and either add
>> additional
>>>> constraints or allow alternative constraints even if the user does
>> not
>>>> have the original permission that triggered it all); this is
>> recursive
>>>> so that if an alternative permission is configured that permission
>> may
>>>> also have further alternative permissions; also being recursive if
>>
>>>> attached logic evaluates other permissions that may have
>> alternative
>>>> permissions and/or permission logic attached to them; as I
>> understand
>>>> what Andrew has implemented, this is the pattern he followed
>>>>
>>>> 4. artifacts are not responsible for their own security except to
>>>> specify whether any sort of permission is required or not (ie a
>>>> require-permission attribute, would be true by default; for example
>>
>>>> most ecommerce screens would have this set to false); access
>> control
>>>> would be configured externally so that you can configure access at
>> the
>>>> most granular level possible (we would go ALL the way here,
>> including:
>>>> screens, services, forms, form fields, menu items, tree nodes, etc,
>>
>>>> etc); the access control tools would have patterns and features to
>>
>>>> facilitate grouping of artifacts, grouping of users (ie just use
>> the
>>>> current SecurityGroup entity), and support for both functionality
>>>> access and record-level access
>>>>
>>>> Can anyone thing of other patterns? Again, PLEASE do not comment on
>>
>>>> which one you like better or what you think the advantages or
>>>> disadvantages are of each in this thread (of course, definitely
>> think
>>>> about such things and feel free to comment in other threads, I just
>>
>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>>
>>>> give it a go!) brainstorming session.
>>>>
>>>> Thank You!
>>>> -David
>>>>
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
I have the design document ready, I just don't know what to do with it.

-Adrian

David E Jones wrote:

>
> I think the sentiment in the thread is that more feedback would be
> really helpful. It's kind of the lack of discussion that seems to be
> holding this back.
>
> At this point I don't see any comments that argue against item #4, so
> unless someone hops in with comments, issues, or additional requirements
> then we'll just go with that.
>
> The next step, aside from the work that Adrian is doing, is to get the
> data model going for this external configuration of authorization that
> fits for this pattern and the requirements in the other thread.
>
> -David
>
>
> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>
>> +1 - that's what I was saying - let's get back on this horse and make
>> these improvements!  We all know it's sorely needed - don't let
>> discussion stop us from making an impact.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>> ----- "Adrian Crum" <[hidden email]> wrote:
>>
>>> I'm sure it is no surprise that I like the #4 design the best - I
>>> think
>>> it matches the design I proposed.
>>>
>>> What IS surprising is the lack of response. We had a lively discussion
>>>
>>> on the subject of security design a week ago, and now there doesn't
>>> seem
>>> to be much interest in it.
>>>
>>> -Adrian
>>>
>>>
>>> David E Jones wrote:
>>>>
>>>> I haven't seen any additions to this original list in the attempt to
>>>
>>>> brainstorm, so I guess we're ready to start discussing the merits of
>>>
>>>> each of these approaches.
>>>>
>>>> Please comment!
>>>>
>>>> To get this started I'll express my opinions on the topic. In short,
>>> #4
>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>> here's
>>>> why I say that. Right now in order to configure permissions and
>>>> introduce more granular permissions as needed you have to edit some
>>> sort
>>>> of XML files (or in some case Java files or other things) possibly
>>>> including screen defs, service defs, and service implementations.
>>> The
>>>> most important part of point #4 is that authorization settings will
>>> be
>>>> totally external to these artifacts. In other words, the
>>> authorization
>>>> settings will refer to the various artifacts instead of the
>>> artifacts
>>>> pointing to the authorization settings.
>>>>
>>>> IMO that's the most important point: if security can't be configured
>>> by
>>>> an end-user and through run-time evaluated data (preferably in the
>>>> database so multiple app servers stay consistent, etc), then what's
>>> the
>>>> point? The security config in OFBiz would still be a large,
>>> expensive,
>>>> PITA.
>>>>
>>>> That said, other biased comments are now needed to balance the bias
>>> I
>>>> just threw into this... ;)
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>
>>>>>
>>>>> This thread is specifically for discussing possible configuration
>>>>> patterns to use in OFBiz going forward. Please keep other
>>> discussion
>>>>> in another thread, including the merits of each possibility...
>>> let's
>>>>> just brainstorm in this thread.
>>>>>
>>>>> To get things started, here are the patterns that have been
>>> discussed
>>>>> recently (in high level terms, we can get into implementation and
>>>>> specific practices later on), these are in no particular order:
>>>>>
>>>>> 1. artifacts responsible for their own security (especially
>>> services
>>>>> and screens), and security permissions are referred to directly (ie
>>>
>>>>> the actual permissions are configured directly in the XML tags for
>>> the
>>>>> artifact)
>>>>>
>>>>> 2. artifacts responsible for their own security, and no direct
>>>>> references are used and instead an indirect security control is
>>>>> referred to; this is basically the permission service model we've
>>> been
>>>>> using where a permission service is basically a security policy
>>> that
>>>>> refers to permissions, can query/filter/whatever to do record level
>>>
>>>>> security, and in customization the permission service can be
>>>>> overridden or its function changed by ECA rules without touching
>>> any
>>>>> OOTB code or configuration
>>>>>
>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>> permissions
>>>>> and there is external configuration based on those permissions that
>>>
>>>>> can add other qualifying permissions and/or invoke logic to change
>>> how
>>>>> that permission is evaluated (ie override the default behavior of
>>>>> requiring the user to have that permission and either add
>>> additional
>>>>> constraints or allow alternative constraints even if the user does
>>> not
>>>>> have the original permission that triggered it all); this is
>>> recursive
>>>>> so that if an alternative permission is configured that permission
>>> may
>>>>> also have further alternative permissions; also being recursive if
>>>
>>>>> attached logic evaluates other permissions that may have
>>> alternative
>>>>> permissions and/or permission logic attached to them; as I
>>> understand
>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>
>>>>> 4. artifacts are not responsible for their own security except to
>>>>> specify whether any sort of permission is required or not (ie a
>>>>> require-permission attribute, would be true by default; for example
>>>
>>>>> most ecommerce screens would have this set to false); access
>>> control
>>>>> would be configured externally so that you can configure access at
>>> the
>>>>> most granular level possible (we would go ALL the way here,
>>> including:
>>>>> screens, services, forms, form fields, menu items, tree nodes, etc,
>>>
>>>>> etc); the access control tools would have patterns and features to
>>>
>>>>> facilitate grouping of artifacts, grouping of users (ie just use
>>> the
>>>>> current SecurityGroup entity), and support for both functionality
>>>>> access and record-level access
>>>>>
>>>>> Can anyone thing of other patterns? Again, PLEASE do not comment on
>>>
>>>>> which one you like better or what you think the advantages or
>>>>> disadvantages are of each in this thread (of course, definitely
>>> think
>>>>> about such things and feel free to comment in other threads, I just
>>>
>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>>>
>>>>> give it a go!) brainstorming session.
>>>>>
>>>>> Thank You!
>>>>> -David
>>>>>
>>>>
>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3

Okay, I give up trying to find it or a link to in my email history...  
where is your document Adrian?

-David


On May 13, 2009, at 12:58 PM, Adrian Crum wrote:

> I have the design document ready, I just don't know what to do with  
> it.
>
> -Adrian
>
> David E Jones wrote:
>> I think the sentiment in the thread is that more feedback would be  
>> really helpful. It's kind of the lack of discussion that seems to  
>> be holding this back.
>> At this point I don't see any comments that argue against item #4,  
>> so unless someone hops in with comments, issues, or additional  
>> requirements then we'll just go with that.
>> The next step, aside from the work that Adrian is doing, is to get  
>> the data model going for this external configuration of  
>> authorization that fits for this pattern and the requirements in  
>> the other thread.
>> -David
>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>> +1 - that's what I was saying - let's get back on this horse and  
>>> make these improvements!  We all know it's sorely needed - don't  
>>> let discussion stop us from making an impact.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>
>>>> I'm sure it is no surprise that I like the #4 design the best - I
>>>> think
>>>> it matches the design I proposed.
>>>>
>>>> What IS surprising is the lack of response. We had a lively  
>>>> discussion
>>>>
>>>> on the subject of security design a week ago, and now there doesn't
>>>> seem
>>>> to be much interest in it.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> David E Jones wrote:
>>>>>
>>>>> I haven't seen any additions to this original list in the  
>>>>> attempt to
>>>>
>>>>> brainstorm, so I guess we're ready to start discussing the  
>>>>> merits of
>>>>
>>>>> each of these approaches.
>>>>>
>>>>> Please comment!
>>>>>
>>>>> To get this started I'll express my opinions on the topic. In  
>>>>> short,
>>>> #4
>>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>>> here's
>>>>> why I say that. Right now in order to configure permissions and
>>>>> introduce more granular permissions as needed you have to edit  
>>>>> some
>>>> sort
>>>>> of XML files (or in some case Java files or other things) possibly
>>>>> including screen defs, service defs, and service implementations.
>>>> The
>>>>> most important part of point #4 is that authorization settings  
>>>>> will
>>>> be
>>>>> totally external to these artifacts. In other words, the
>>>> authorization
>>>>> settings will refer to the various artifacts instead of the
>>>> artifacts
>>>>> pointing to the authorization settings.
>>>>>
>>>>> IMO that's the most important point: if security can't be  
>>>>> configured
>>>> by
>>>>> an end-user and through run-time evaluated data (preferably in the
>>>>> database so multiple app servers stay consistent, etc), then  
>>>>> what's
>>>> the
>>>>> point? The security config in OFBiz would still be a large,
>>>> expensive,
>>>>> PITA.
>>>>>
>>>>> That said, other biased comments are now needed to balance the  
>>>>> bias
>>>> I
>>>>> just threw into this... ;)
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>
>>>>>>
>>>>>> This thread is specifically for discussing possible configuration
>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>> discussion
>>>>>> in another thread, including the merits of each possibility...
>>>> let's
>>>>>> just brainstorm in this thread.
>>>>>>
>>>>>> To get things started, here are the patterns that have been
>>>> discussed
>>>>>> recently (in high level terms, we can get into implementation and
>>>>>> specific practices later on), these are in no particular order:
>>>>>>
>>>>>> 1. artifacts responsible for their own security (especially
>>>> services
>>>>>> and screens), and security permissions are referred to directly  
>>>>>> (ie
>>>>
>>>>>> the actual permissions are configured directly in the XML tags  
>>>>>> for
>>>> the
>>>>>> artifact)
>>>>>>
>>>>>> 2. artifacts responsible for their own security, and no direct
>>>>>> references are used and instead an indirect security control is
>>>>>> referred to; this is basically the permission service model we've
>>>> been
>>>>>> using where a permission service is basically a security policy
>>>> that
>>>>>> refers to permissions, can query/filter/whatever to do record  
>>>>>> level
>>>>
>>>>>> security, and in customization the permission service can be
>>>>>> overridden or its function changed by ECA rules without touching
>>>> any
>>>>>> OOTB code or configuration
>>>>>>
>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>> permissions
>>>>>> and there is external configuration based on those permissions  
>>>>>> that
>>>>
>>>>>> can add other qualifying permissions and/or invoke logic to  
>>>>>> change
>>>> how
>>>>>> that permission is evaluated (ie override the default behavior of
>>>>>> requiring the user to have that permission and either add
>>>> additional
>>>>>> constraints or allow alternative constraints even if the user  
>>>>>> does
>>>> not
>>>>>> have the original permission that triggered it all); this is
>>>> recursive
>>>>>> so that if an alternative permission is configured that  
>>>>>> permission
>>>> may
>>>>>> also have further alternative permissions; also being recursive  
>>>>>> if
>>>>
>>>>>> attached logic evaluates other permissions that may have
>>>> alternative
>>>>>> permissions and/or permission logic attached to them; as I
>>>> understand
>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>
>>>>>> 4. artifacts are not responsible for their own security except to
>>>>>> specify whether any sort of permission is required or not (ie a
>>>>>> require-permission attribute, would be true by default; for  
>>>>>> example
>>>>
>>>>>> most ecommerce screens would have this set to false); access
>>>> control
>>>>>> would be configured externally so that you can configure access  
>>>>>> at
>>>> the
>>>>>> most granular level possible (we would go ALL the way here,
>>>> including:
>>>>>> screens, services, forms, form fields, menu items, tree nodes,  
>>>>>> etc,
>>>>
>>>>>> etc); the access control tools would have patterns and features  
>>>>>> to
>>>>
>>>>>> facilitate grouping of artifacts, grouping of users (ie just use
>>>> the
>>>>>> current SecurityGroup entity), and support for both functionality
>>>>>> access and record-level access
>>>>>>
>>>>>> Can anyone thing of other patterns? Again, PLEASE do not  
>>>>>> comment on
>>>>
>>>>>> which one you like better or what you think the advantages or
>>>>>> disadvantages are of each in this thread (of course, definitely
>>>> think
>>>>>> about such things and feel free to comment in other threads, I  
>>>>>> just
>>>>
>>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that  
>>>>>> should
>>>>
>>>>>> give it a go!) brainstorming session.
>>>>>>
>>>>>> Thank You!
>>>>>> -David
>>>>>>
>>>>>
>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
lol - that's what I was asking you. I have the document ready, where
should I put it where everyone can find it? Do we want to create a Wiki
page or Jira issue? I'm sure we will need some place to collaborate.

-Adrian


David E Jones wrote:

>
> Okay, I give up trying to find it or a link to in my email history...
> where is your document Adrian?
>
> -David
>
>
> On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
>
>> I have the design document ready, I just don't know what to do with it.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> I think the sentiment in the thread is that more feedback would be
>>> really helpful. It's kind of the lack of discussion that seems to be
>>> holding this back.
>>> At this point I don't see any comments that argue against item #4, so
>>> unless someone hops in with comments, issues, or additional
>>> requirements then we'll just go with that.
>>> The next step, aside from the work that Adrian is doing, is to get
>>> the data model going for this external configuration of authorization
>>> that fits for this pattern and the requirements in the other thread.
>>> -David
>>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>>> +1 - that's what I was saying - let's get back on this horse and
>>>> make these improvements!  We all know it's sorely needed - don't let
>>>> discussion stop us from making an impact.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>>
>>>>> I'm sure it is no surprise that I like the #4 design the best - I
>>>>> think
>>>>> it matches the design I proposed.
>>>>>
>>>>> What IS surprising is the lack of response. We had a lively discussion
>>>>>
>>>>> on the subject of security design a week ago, and now there doesn't
>>>>> seem
>>>>> to be much interest in it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> David E Jones wrote:
>>>>>>
>>>>>> I haven't seen any additions to this original list in the attempt to
>>>>>
>>>>>> brainstorm, so I guess we're ready to start discussing the merits of
>>>>>
>>>>>> each of these approaches.
>>>>>>
>>>>>> Please comment!
>>>>>>
>>>>>> To get this started I'll express my opinions on the topic. In short,
>>>>> #4
>>>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>>>> here's
>>>>>> why I say that. Right now in order to configure permissions and
>>>>>> introduce more granular permissions as needed you have to edit some
>>>>> sort
>>>>>> of XML files (or in some case Java files or other things) possibly
>>>>>> including screen defs, service defs, and service implementations.
>>>>> The
>>>>>> most important part of point #4 is that authorization settings will
>>>>> be
>>>>>> totally external to these artifacts. In other words, the
>>>>> authorization
>>>>>> settings will refer to the various artifacts instead of the
>>>>> artifacts
>>>>>> pointing to the authorization settings.
>>>>>>
>>>>>> IMO that's the most important point: if security can't be configured
>>>>> by
>>>>>> an end-user and through run-time evaluated data (preferably in the
>>>>>> database so multiple app servers stay consistent, etc), then what's
>>>>> the
>>>>>> point? The security config in OFBiz would still be a large,
>>>>> expensive,
>>>>>> PITA.
>>>>>>
>>>>>> That said, other biased comments are now needed to balance the bias
>>>>> I
>>>>>> just threw into this... ;)
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>>
>>>>>>>
>>>>>>> This thread is specifically for discussing possible configuration
>>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>>> discussion
>>>>>>> in another thread, including the merits of each possibility...
>>>>> let's
>>>>>>> just brainstorm in this thread.
>>>>>>>
>>>>>>> To get things started, here are the patterns that have been
>>>>> discussed
>>>>>>> recently (in high level terms, we can get into implementation and
>>>>>>> specific practices later on), these are in no particular order:
>>>>>>>
>>>>>>> 1. artifacts responsible for their own security (especially
>>>>> services
>>>>>>> and screens), and security permissions are referred to directly (ie
>>>>>
>>>>>>> the actual permissions are configured directly in the XML tags for
>>>>> the
>>>>>>> artifact)
>>>>>>>
>>>>>>> 2. artifacts responsible for their own security, and no direct
>>>>>>> references are used and instead an indirect security control is
>>>>>>> referred to; this is basically the permission service model we've
>>>>> been
>>>>>>> using where a permission service is basically a security policy
>>>>> that
>>>>>>> refers to permissions, can query/filter/whatever to do record level
>>>>>
>>>>>>> security, and in customization the permission service can be
>>>>>>> overridden or its function changed by ECA rules without touching
>>>>> any
>>>>>>> OOTB code or configuration
>>>>>>>
>>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>>> permissions
>>>>>>> and there is external configuration based on those permissions that
>>>>>
>>>>>>> can add other qualifying permissions and/or invoke logic to change
>>>>> how
>>>>>>> that permission is evaluated (ie override the default behavior of
>>>>>>> requiring the user to have that permission and either add
>>>>> additional
>>>>>>> constraints or allow alternative constraints even if the user does
>>>>> not
>>>>>>> have the original permission that triggered it all); this is
>>>>> recursive
>>>>>>> so that if an alternative permission is configured that permission
>>>>> may
>>>>>>> also have further alternative permissions; also being recursive if
>>>>>
>>>>>>> attached logic evaluates other permissions that may have
>>>>> alternative
>>>>>>> permissions and/or permission logic attached to them; as I
>>>>> understand
>>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>>
>>>>>>> 4. artifacts are not responsible for their own security except to
>>>>>>> specify whether any sort of permission is required or not (ie a
>>>>>>> require-permission attribute, would be true by default; for example
>>>>>
>>>>>>> most ecommerce screens would have this set to false); access
>>>>> control
>>>>>>> would be configured externally so that you can configure access at
>>>>> the
>>>>>>> most granular level possible (we would go ALL the way here,
>>>>> including:
>>>>>>> screens, services, forms, form fields, menu items, tree nodes, etc,
>>>>>
>>>>>>> etc); the access control tools would have patterns and features to
>>>>>
>>>>>>> facilitate grouping of artifacts, grouping of users (ie just use
>>>>> the
>>>>>>> current SecurityGroup entity), and support for both functionality
>>>>>>> access and record-level access
>>>>>>>
>>>>>>> Can anyone thing of other patterns? Again, PLEASE do not comment on
>>>>>
>>>>>>> which one you like better or what you think the advantages or
>>>>>>> disadvantages are of each in this thread (of course, definitely
>>>>> think
>>>>>>> about such things and feel free to comment in other threads, I just
>>>>>
>>>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that should
>>>>>
>>>>>>> give it a go!) brainstorming session.
>>>>>>>
>>>>>>> Thank You!
>>>>>>> -David
>>>>>>>
>>>>>>
>>>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3

Well, THAT explains it!

A wiki page is probably the best place for things like this (that's  
where I found myself looking anyway...). That will allow collaboration  
on working the document and getting things setup for development.

-David


On May 13, 2009, at 2:14 PM, Adrian Crum wrote:

> lol - that's what I was asking you. I have the document ready, where  
> should I put it where everyone can find it? Do we want to create a  
> Wiki page or Jira issue? I'm sure we will need some place to  
> collaborate.
>
> -Adrian
>
>
> David E Jones wrote:
>> Okay, I give up trying to find it or a link to in my email  
>> history... where is your document Adrian?
>> -David
>> On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
>>> I have the design document ready, I just don't know what to do  
>>> with it.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> I think the sentiment in the thread is that more feedback would  
>>>> be really helpful. It's kind of the lack of discussion that seems  
>>>> to be holding this back.
>>>> At this point I don't see any comments that argue against item  
>>>> #4, so unless someone hops in with comments, issues, or  
>>>> additional requirements then we'll just go with that.
>>>> The next step, aside from the work that Adrian is doing, is to  
>>>> get the data model going for this external configuration of  
>>>> authorization that fits for this pattern and the requirements in  
>>>> the other thread.
>>>> -David
>>>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>>>> +1 - that's what I was saying - let's get back on this horse and  
>>>>> make these improvements!  We all know it's sorely needed - don't  
>>>>> let discussion stop us from making an impact.
>>>>>
>>>>> Cheers,
>>>>> Tim
>>>>> --
>>>>> Tim Ruppert
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> o:801.649.6594
>>>>> f:801.649.6595
>>>>>
>>>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>>>
>>>>>> I'm sure it is no surprise that I like the #4 design the best - I
>>>>>> think
>>>>>> it matches the design I proposed.
>>>>>>
>>>>>> What IS surprising is the lack of response. We had a lively  
>>>>>> discussion
>>>>>>
>>>>>> on the subject of security design a week ago, and now there  
>>>>>> doesn't
>>>>>> seem
>>>>>> to be much interest in it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>>
>>>>>>> I haven't seen any additions to this original list in the  
>>>>>>> attempt to
>>>>>>
>>>>>>> brainstorm, so I guess we're ready to start discussing the  
>>>>>>> merits of
>>>>>>
>>>>>>> each of these approaches.
>>>>>>>
>>>>>>> Please comment!
>>>>>>>
>>>>>>> To get this started I'll express my opinions on the topic. In  
>>>>>>> short,
>>>>>> #4
>>>>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>>>>> here's
>>>>>>> why I say that. Right now in order to configure permissions and
>>>>>>> introduce more granular permissions as needed you have to edit  
>>>>>>> some
>>>>>> sort
>>>>>>> of XML files (or in some case Java files or other things)  
>>>>>>> possibly
>>>>>>> including screen defs, service defs, and service  
>>>>>>> implementations.
>>>>>> The
>>>>>>> most important part of point #4 is that authorization settings  
>>>>>>> will
>>>>>> be
>>>>>>> totally external to these artifacts. In other words, the
>>>>>> authorization
>>>>>>> settings will refer to the various artifacts instead of the
>>>>>> artifacts
>>>>>>> pointing to the authorization settings.
>>>>>>>
>>>>>>> IMO that's the most important point: if security can't be  
>>>>>>> configured
>>>>>> by
>>>>>>> an end-user and through run-time evaluated data (preferably in  
>>>>>>> the
>>>>>>> database so multiple app servers stay consistent, etc), then  
>>>>>>> what's
>>>>>> the
>>>>>>> point? The security config in OFBiz would still be a large,
>>>>>> expensive,
>>>>>>> PITA.
>>>>>>>
>>>>>>> That said, other biased comments are now needed to balance the  
>>>>>>> bias
>>>>>> I
>>>>>>> just threw into this... ;)
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> This thread is specifically for discussing possible  
>>>>>>>> configuration
>>>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>>>> discussion
>>>>>>>> in another thread, including the merits of each possibility...
>>>>>> let's
>>>>>>>> just brainstorm in this thread.
>>>>>>>>
>>>>>>>> To get things started, here are the patterns that have been
>>>>>> discussed
>>>>>>>> recently (in high level terms, we can get into implementation  
>>>>>>>> and
>>>>>>>> specific practices later on), these are in no particular order:
>>>>>>>>
>>>>>>>> 1. artifacts responsible for their own security (especially
>>>>>> services
>>>>>>>> and screens), and security permissions are referred to  
>>>>>>>> directly (ie
>>>>>>
>>>>>>>> the actual permissions are configured directly in the XML  
>>>>>>>> tags for
>>>>>> the
>>>>>>>> artifact)
>>>>>>>>
>>>>>>>> 2. artifacts responsible for their own security, and no direct
>>>>>>>> references are used and instead an indirect security control is
>>>>>>>> referred to; this is basically the permission service model  
>>>>>>>> we've
>>>>>> been
>>>>>>>> using where a permission service is basically a security policy
>>>>>> that
>>>>>>>> refers to permissions, can query/filter/whatever to do record  
>>>>>>>> level
>>>>>>
>>>>>>>> security, and in customization the permission service can be
>>>>>>>> overridden or its function changed by ECA rules without  
>>>>>>>> touching
>>>>>> any
>>>>>>>> OOTB code or configuration
>>>>>>>>
>>>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>>>> permissions
>>>>>>>> and there is external configuration based on those  
>>>>>>>> permissions that
>>>>>>
>>>>>>>> can add other qualifying permissions and/or invoke logic to  
>>>>>>>> change
>>>>>> how
>>>>>>>> that permission is evaluated (ie override the default  
>>>>>>>> behavior of
>>>>>>>> requiring the user to have that permission and either add
>>>>>> additional
>>>>>>>> constraints or allow alternative constraints even if the user  
>>>>>>>> does
>>>>>> not
>>>>>>>> have the original permission that triggered it all); this is
>>>>>> recursive
>>>>>>>> so that if an alternative permission is configured that  
>>>>>>>> permission
>>>>>> may
>>>>>>>> also have further alternative permissions; also being  
>>>>>>>> recursive if
>>>>>>
>>>>>>>> attached logic evaluates other permissions that may have
>>>>>> alternative
>>>>>>>> permissions and/or permission logic attached to them; as I
>>>>>> understand
>>>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>>>
>>>>>>>> 4. artifacts are not responsible for their own security  
>>>>>>>> except to
>>>>>>>> specify whether any sort of permission is required or not (ie a
>>>>>>>> require-permission attribute, would be true by default; for  
>>>>>>>> example
>>>>>>
>>>>>>>> most ecommerce screens would have this set to false); access
>>>>>> control
>>>>>>>> would be configured externally so that you can configure  
>>>>>>>> access at
>>>>>> the
>>>>>>>> most granular level possible (we would go ALL the way here,
>>>>>> including:
>>>>>>>> screens, services, forms, form fields, menu items, tree  
>>>>>>>> nodes, etc,
>>>>>>
>>>>>>>> etc); the access control tools would have patterns and  
>>>>>>>> features to
>>>>>>
>>>>>>>> facilitate grouping of artifacts, grouping of users (ie just  
>>>>>>>> use
>>>>>> the
>>>>>>>> current SecurityGroup entity), and support for both  
>>>>>>>> functionality
>>>>>>>> access and record-level access
>>>>>>>>
>>>>>>>> Can anyone thing of other patterns? Again, PLEASE do not  
>>>>>>>> comment on
>>>>>>
>>>>>>>> which one you like better or what you think the advantages or
>>>>>>>> disadvantages are of each in this thread (of course, definitely
>>>>>> think
>>>>>>>> about such things and feel free to comment in other threads,  
>>>>>>>> I just
>>>>>>
>>>>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that  
>>>>>>>> should
>>>>>>
>>>>>>>> give it a go!) brainstorming session.
>>>>>>>>
>>>>>>>> Thank You!
>>>>>>>> -David
>>>>>>>>
>>>>>>>
>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
Cool - thanks. I was going to post it as a PDF, but I can C&P it into a
Wiki page.

-Adrian

David E Jones wrote:

>
> Well, THAT explains it!
>
> A wiki page is probably the best place for things like this (that's
> where I found myself looking anyway...). That will allow collaboration
> on working the document and getting things setup for development.
>
> -David
>
>
> On May 13, 2009, at 2:14 PM, Adrian Crum wrote:
>
>> lol - that's what I was asking you. I have the document ready, where
>> should I put it where everyone can find it? Do we want to create a
>> Wiki page or Jira issue? I'm sure we will need some place to collaborate.
>>
>> -Adrian
>>
>>
>> David E Jones wrote:
>>> Okay, I give up trying to find it or a link to in my email history...
>>> where is your document Adrian?
>>> -David
>>> On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
>>>> I have the design document ready, I just don't know what to do with it.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> I think the sentiment in the thread is that more feedback would be
>>>>> really helpful. It's kind of the lack of discussion that seems to
>>>>> be holding this back.
>>>>> At this point I don't see any comments that argue against item #4,
>>>>> so unless someone hops in with comments, issues, or additional
>>>>> requirements then we'll just go with that.
>>>>> The next step, aside from the work that Adrian is doing, is to get
>>>>> the data model going for this external configuration of
>>>>> authorization that fits for this pattern and the requirements in
>>>>> the other thread.
>>>>> -David
>>>>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>>>>> +1 - that's what I was saying - let's get back on this horse and
>>>>>> make these improvements!  We all know it's sorely needed - don't
>>>>>> let discussion stop us from making an impact.
>>>>>>
>>>>>> Cheers,
>>>>>> Tim
>>>>>> --
>>>>>> Tim Ruppert
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> o:801.649.6594
>>>>>> f:801.649.6595
>>>>>>
>>>>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>>>>
>>>>>>> I'm sure it is no surprise that I like the #4 design the best - I
>>>>>>> think
>>>>>>> it matches the design I proposed.
>>>>>>>
>>>>>>> What IS surprising is the lack of response. We had a lively
>>>>>>> discussion
>>>>>>>
>>>>>>> on the subject of security design a week ago, and now there doesn't
>>>>>>> seem
>>>>>>> to be much interest in it.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>>
>>>>>>>> I haven't seen any additions to this original list in the
>>>>>>>> attempt to
>>>>>>>
>>>>>>>> brainstorm, so I guess we're ready to start discussing the
>>>>>>>> merits of
>>>>>>>
>>>>>>>> each of these approaches.
>>>>>>>>
>>>>>>>> Please comment!
>>>>>>>>
>>>>>>>> To get this started I'll express my opinions on the topic. In
>>>>>>>> short,
>>>>>>> #4
>>>>>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>>>>>> here's
>>>>>>>> why I say that. Right now in order to configure permissions and
>>>>>>>> introduce more granular permissions as needed you have to edit some
>>>>>>> sort
>>>>>>>> of XML files (or in some case Java files or other things) possibly
>>>>>>>> including screen defs, service defs, and service implementations.
>>>>>>> The
>>>>>>>> most important part of point #4 is that authorization settings will
>>>>>>> be
>>>>>>>> totally external to these artifacts. In other words, the
>>>>>>> authorization
>>>>>>>> settings will refer to the various artifacts instead of the
>>>>>>> artifacts
>>>>>>>> pointing to the authorization settings.
>>>>>>>>
>>>>>>>> IMO that's the most important point: if security can't be
>>>>>>>> configured
>>>>>>> by
>>>>>>>> an end-user and through run-time evaluated data (preferably in the
>>>>>>>> database so multiple app servers stay consistent, etc), then what's
>>>>>>> the
>>>>>>>> point? The security config in OFBiz would still be a large,
>>>>>>> expensive,
>>>>>>>> PITA.
>>>>>>>>
>>>>>>>> That said, other biased comments are now needed to balance the bias
>>>>>>> I
>>>>>>>> just threw into this... ;)
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This thread is specifically for discussing possible configuration
>>>>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>>>>> discussion
>>>>>>>>> in another thread, including the merits of each possibility...
>>>>>>> let's
>>>>>>>>> just brainstorm in this thread.
>>>>>>>>>
>>>>>>>>> To get things started, here are the patterns that have been
>>>>>>> discussed
>>>>>>>>> recently (in high level terms, we can get into implementation and
>>>>>>>>> specific practices later on), these are in no particular order:
>>>>>>>>>
>>>>>>>>> 1. artifacts responsible for their own security (especially
>>>>>>> services
>>>>>>>>> and screens), and security permissions are referred to directly
>>>>>>>>> (ie
>>>>>>>
>>>>>>>>> the actual permissions are configured directly in the XML tags for
>>>>>>> the
>>>>>>>>> artifact)
>>>>>>>>>
>>>>>>>>> 2. artifacts responsible for their own security, and no direct
>>>>>>>>> references are used and instead an indirect security control is
>>>>>>>>> referred to; this is basically the permission service model we've
>>>>>>> been
>>>>>>>>> using where a permission service is basically a security policy
>>>>>>> that
>>>>>>>>> refers to permissions, can query/filter/whatever to do record
>>>>>>>>> level
>>>>>>>
>>>>>>>>> security, and in customization the permission service can be
>>>>>>>>> overridden or its function changed by ECA rules without touching
>>>>>>> any
>>>>>>>>> OOTB code or configuration
>>>>>>>>>
>>>>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>>>>> permissions
>>>>>>>>> and there is external configuration based on those permissions
>>>>>>>>> that
>>>>>>>
>>>>>>>>> can add other qualifying permissions and/or invoke logic to change
>>>>>>> how
>>>>>>>>> that permission is evaluated (ie override the default behavior of
>>>>>>>>> requiring the user to have that permission and either add
>>>>>>> additional
>>>>>>>>> constraints or allow alternative constraints even if the user does
>>>>>>> not
>>>>>>>>> have the original permission that triggered it all); this is
>>>>>>> recursive
>>>>>>>>> so that if an alternative permission is configured that permission
>>>>>>> may
>>>>>>>>> also have further alternative permissions; also being recursive if
>>>>>>>
>>>>>>>>> attached logic evaluates other permissions that may have
>>>>>>> alternative
>>>>>>>>> permissions and/or permission logic attached to them; as I
>>>>>>> understand
>>>>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>>>>
>>>>>>>>> 4. artifacts are not responsible for their own security except to
>>>>>>>>> specify whether any sort of permission is required or not (ie a
>>>>>>>>> require-permission attribute, would be true by default; for
>>>>>>>>> example
>>>>>>>
>>>>>>>>> most ecommerce screens would have this set to false); access
>>>>>>> control
>>>>>>>>> would be configured externally so that you can configure access at
>>>>>>> the
>>>>>>>>> most granular level possible (we would go ALL the way here,
>>>>>>> including:
>>>>>>>>> screens, services, forms, form fields, menu items, tree nodes,
>>>>>>>>> etc,
>>>>>>>
>>>>>>>>> etc); the access control tools would have patterns and features to
>>>>>>>
>>>>>>>>> facilitate grouping of artifacts, grouping of users (ie just use
>>>>>>> the
>>>>>>>>> current SecurityGroup entity), and support for both functionality
>>>>>>>>> access and record-level access
>>>>>>>>>
>>>>>>>>> Can anyone thing of other patterns? Again, PLEASE do not
>>>>>>>>> comment on
>>>>>>>
>>>>>>>>> which one you like better or what you think the advantages or
>>>>>>>>> disadvantages are of each in this thread (of course, definitely
>>>>>>> think
>>>>>>>>> about such things and feel free to comment in other threads, I
>>>>>>>>> just
>>>>>>>
>>>>>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that
>>>>>>>>> should
>>>>>>>
>>>>>>>>> give it a go!) brainstorming session.
>>>>>>>>>
>>>>>>>>> Thank You!
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
Done - http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor.

I was going to spend more time on it to add more detail, but since we're
in such a hurry I posted it as-is.

-Adrian

Adrian Crum wrote:

> Cool - thanks. I was going to post it as a PDF, but I can C&P it into a
> Wiki page.
>
> -Adrian
>
> David E Jones wrote:
>>
>> Well, THAT explains it!
>>
>> A wiki page is probably the best place for things like this (that's
>> where I found myself looking anyway...). That will allow collaboration
>> on working the document and getting things setup for development.
>>
>> -David
>>
>>
>> On May 13, 2009, at 2:14 PM, Adrian Crum wrote:
>>
>>> lol - that's what I was asking you. I have the document ready, where
>>> should I put it where everyone can find it? Do we want to create a
>>> Wiki page or Jira issue? I'm sure we will need some place to
>>> collaborate.
>>>
>>> -Adrian
>>>
>>>
>>> David E Jones wrote:
>>>> Okay, I give up trying to find it or a link to in my email
>>>> history... where is your document Adrian?
>>>> -David
>>>> On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
>>>>> I have the design document ready, I just don't know what to do with
>>>>> it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> I think the sentiment in the thread is that more feedback would be
>>>>>> really helpful. It's kind of the lack of discussion that seems to
>>>>>> be holding this back.
>>>>>> At this point I don't see any comments that argue against item #4,
>>>>>> so unless someone hops in with comments, issues, or additional
>>>>>> requirements then we'll just go with that.
>>>>>> The next step, aside from the work that Adrian is doing, is to get
>>>>>> the data model going for this external configuration of
>>>>>> authorization that fits for this pattern and the requirements in
>>>>>> the other thread.
>>>>>> -David
>>>>>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>>>>>> +1 - that's what I was saying - let's get back on this horse and
>>>>>>> make these improvements!  We all know it's sorely needed - don't
>>>>>>> let discussion stop us from making an impact.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Tim
>>>>>>> --
>>>>>>> Tim Ruppert
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> o:801.649.6594
>>>>>>> f:801.649.6595
>>>>>>>
>>>>>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>>>>>
>>>>>>>> I'm sure it is no surprise that I like the #4 design the best - I
>>>>>>>> think
>>>>>>>> it matches the design I proposed.
>>>>>>>>
>>>>>>>> What IS surprising is the lack of response. We had a lively
>>>>>>>> discussion
>>>>>>>>
>>>>>>>> on the subject of security design a week ago, and now there doesn't
>>>>>>>> seem
>>>>>>>> to be much interest in it.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> David E Jones wrote:
>>>>>>>>>
>>>>>>>>> I haven't seen any additions to this original list in the
>>>>>>>>> attempt to
>>>>>>>>
>>>>>>>>> brainstorm, so I guess we're ready to start discussing the
>>>>>>>>> merits of
>>>>>>>>
>>>>>>>>> each of these approaches.
>>>>>>>>>
>>>>>>>>> Please comment!
>>>>>>>>>
>>>>>>>>> To get this started I'll express my opinions on the topic. In
>>>>>>>>> short,
>>>>>>>> #4
>>>>>>>>> is cool and 1-3 are crap. Is that biased enough for you? Well,
>>>>>>>> here's
>>>>>>>>> why I say that. Right now in order to configure permissions and
>>>>>>>>> introduce more granular permissions as needed you have to edit
>>>>>>>>> some
>>>>>>>> sort
>>>>>>>>> of XML files (or in some case Java files or other things) possibly
>>>>>>>>> including screen defs, service defs, and service implementations.
>>>>>>>> The
>>>>>>>>> most important part of point #4 is that authorization settings
>>>>>>>>> will
>>>>>>>> be
>>>>>>>>> totally external to these artifacts. In other words, the
>>>>>>>> authorization
>>>>>>>>> settings will refer to the various artifacts instead of the
>>>>>>>> artifacts
>>>>>>>>> pointing to the authorization settings.
>>>>>>>>>
>>>>>>>>> IMO that's the most important point: if security can't be
>>>>>>>>> configured
>>>>>>>> by
>>>>>>>>> an end-user and through run-time evaluated data (preferably in the
>>>>>>>>> database so multiple app servers stay consistent, etc), then
>>>>>>>>> what's
>>>>>>>> the
>>>>>>>>> point? The security config in OFBiz would still be a large,
>>>>>>>> expensive,
>>>>>>>>> PITA.
>>>>>>>>>
>>>>>>>>> That said, other biased comments are now needed to balance the
>>>>>>>>> bias
>>>>>>>> I
>>>>>>>>> just threw into this... ;)
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This thread is specifically for discussing possible configuration
>>>>>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>>>>>> discussion
>>>>>>>>>> in another thread, including the merits of each possibility...
>>>>>>>> let's
>>>>>>>>>> just brainstorm in this thread.
>>>>>>>>>>
>>>>>>>>>> To get things started, here are the patterns that have been
>>>>>>>> discussed
>>>>>>>>>> recently (in high level terms, we can get into implementation and
>>>>>>>>>> specific practices later on), these are in no particular order:
>>>>>>>>>>
>>>>>>>>>> 1. artifacts responsible for their own security (especially
>>>>>>>> services
>>>>>>>>>> and screens), and security permissions are referred to
>>>>>>>>>> directly (ie
>>>>>>>>
>>>>>>>>>> the actual permissions are configured directly in the XML tags
>>>>>>>>>> for
>>>>>>>> the
>>>>>>>>>> artifact)
>>>>>>>>>>
>>>>>>>>>> 2. artifacts responsible for their own security, and no direct
>>>>>>>>>> references are used and instead an indirect security control is
>>>>>>>>>> referred to; this is basically the permission service model we've
>>>>>>>> been
>>>>>>>>>> using where a permission service is basically a security policy
>>>>>>>> that
>>>>>>>>>> refers to permissions, can query/filter/whatever to do record
>>>>>>>>>> level
>>>>>>>>
>>>>>>>>>> security, and in customization the permission service can be
>>>>>>>>>> overridden or its function changed by ECA rules without touching
>>>>>>>> any
>>>>>>>>>> OOTB code or configuration
>>>>>>>>>>
>>>>>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>>>>>> permissions
>>>>>>>>>> and there is external configuration based on those permissions
>>>>>>>>>> that
>>>>>>>>
>>>>>>>>>> can add other qualifying permissions and/or invoke logic to
>>>>>>>>>> change
>>>>>>>> how
>>>>>>>>>> that permission is evaluated (ie override the default behavior of
>>>>>>>>>> requiring the user to have that permission and either add
>>>>>>>> additional
>>>>>>>>>> constraints or allow alternative constraints even if the user
>>>>>>>>>> does
>>>>>>>> not
>>>>>>>>>> have the original permission that triggered it all); this is
>>>>>>>> recursive
>>>>>>>>>> so that if an alternative permission is configured that
>>>>>>>>>> permission
>>>>>>>> may
>>>>>>>>>> also have further alternative permissions; also being
>>>>>>>>>> recursive if
>>>>>>>>
>>>>>>>>>> attached logic evaluates other permissions that may have
>>>>>>>> alternative
>>>>>>>>>> permissions and/or permission logic attached to them; as I
>>>>>>>> understand
>>>>>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>>>>>
>>>>>>>>>> 4. artifacts are not responsible for their own security except to
>>>>>>>>>> specify whether any sort of permission is required or not (ie a
>>>>>>>>>> require-permission attribute, would be true by default; for
>>>>>>>>>> example
>>>>>>>>
>>>>>>>>>> most ecommerce screens would have this set to false); access
>>>>>>>> control
>>>>>>>>>> would be configured externally so that you can configure
>>>>>>>>>> access at
>>>>>>>> the
>>>>>>>>>> most granular level possible (we would go ALL the way here,
>>>>>>>> including:
>>>>>>>>>> screens, services, forms, form fields, menu items, tree nodes,
>>>>>>>>>> etc,
>>>>>>>>
>>>>>>>>>> etc); the access control tools would have patterns and
>>>>>>>>>> features to
>>>>>>>>
>>>>>>>>>> facilitate grouping of artifacts, grouping of users (ie just use
>>>>>>>> the
>>>>>>>>>> current SecurityGroup entity), and support for both functionality
>>>>>>>>>> access and record-level access
>>>>>>>>>>
>>>>>>>>>> Can anyone thing of other patterns? Again, PLEASE do not
>>>>>>>>>> comment on
>>>>>>>>
>>>>>>>>>> which one you like better or what you think the advantages or
>>>>>>>>>> disadvantages are of each in this thread (of course, definitely
>>>>>>>> think
>>>>>>>>>> about such things and feel free to comment in other threads, I
>>>>>>>>>> just
>>>>>>>>
>>>>>>>>>> want this to be a "hat's off" (yes, that is a reference to Six
>>>>>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read that
>>>>>>>>>> should
>>>>>>>>
>>>>>>>>>> give it a go!) brainstorming session.
>>>>>>>>>>
>>>>>>>>>> Thank You!
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

David E Jones-3

Thanks for your effort on this Adrian.

A few points of feedback (written as I read through this):

1. the hierarchy of artifacts should not be static as you have  
described; what we care about for access control is how an artifact is  
used, not where it is statically located; for example we don't care if  
the AcctgTransEntry entity is part of the accounting component, but we  
do care if it is used by service X or in screen Y or in webapp Z; in  
other words, the hierarchical description for the context of a  
resource isn't static, it is built up at run-time as things are being  
executed; this is a big problem with the current security stuff, and  
something Andrew started to address but that wasn't fully fleshed out

1-Redux. jumping back to this comment after reading the "Artifact  
Reuse" section: this starts to address the issues of artifacts being  
used in different places, but I'm not sure if the idea of the  
hierarchical string adequately addresses the issues since the chain of  
artifacts used will vary in dramatic ways for different operations, ie  
for a larger webapp request and response you'd have a huge tree of  
artifacts called, and they would be different and in different orders  
than artifacts called in other requests; I've been writing up an  
entity model and some implementation notes to support features implied  
by the model (based on some of these discussions) and I have some  
ideas about how we might configure to support this concept, and what  
the implementation might look like (isn't actually too complicated,  
but there are some important/key points)

2. I don't like the idea of "User Group", "User Role" and "Policy"; it  
is confusing to have the multiple terms that mean slightly different  
things, and things that overlap in some ways with existing OFBiz  
concepts; I also don't think we need 2 levels of grouping between a  
user and what it has access to; in other words the current  
SecurityGroup that is used instead of referring directly to users is  
adequate as it takes care of not having to duplicate access control  
configuration for multiple users without adding too much complexity; I  
know this came from discussion in an email thread, but this seems to  
include every possible idea and try to make them fit together somehow  
instead of picking a single concept and making it work; in other words  
if someone is used to calling something a "role" or a "group" or a  
"policy" it won't make it any simpler if they get into the UI and all  
three are present and all three used in slightly different ways from  
what they are used to... the goal to make it easy for users of other  
systems to use it fails, and the goal to make it work well on its own  
also fails; hopefully this is okay, and I think so based on your  
comments in a blue info box about just using the User Groups (and  
hopefully I've expressed why I agree with that approach here)

3. we should support services to check authorization and also support  
configuration of record-level permissions; in most cases these are  
really simple with just a view-entity that goes between the  
userLoginId or partyId and some other end-point, like a productId or a  
partyId, with specific constraints along the way (like a  
productCategoryI, productCategoryTypeId, roleTypeId,  
partyRelationshipTypeId, etc); for the most part I think we should try  
to eliminate the services that do permission checks and instead make  
it all configurable; also, if there is a service involved it should be  
referenced in the database-driven configuration and NOT in the  
artifact itself (again the goal is to get those out of the artifacts  
so that they are more readily and flexibly configurable)

Anyway, that said I think this going in just the right direction and I  
look forward to comments from others on this too (it would be great to  
see discussions about actual aspects of requirements, design, and  
implementation to get as much action as discussions of how we  
collaborate... ie hopefully we'll do more collaborating than talking  
about if and how to collaborate... ;) ).

I have posted my notes at the bottom of the page you created (http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor 
). Hopefully those will help clarify what I tried to describe above in  
this message, and also lay some groundwork for the technical design.  
For that as well comments are welcome (and hoped for!).

-David


On May 13, 2009, at 3:10 PM, Adrian Crum wrote:

> Done - http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor.
>
> I was going to spend more time on it to add more detail, but since  
> we're in such a hurry I posted it as-is.
>
> -Adrian
>
> Adrian Crum wrote:
>> Cool - thanks. I was going to post it as a PDF, but I can C&P it  
>> into a Wiki page.
>> -Adrian
>> David E Jones wrote:
>>>
>>> Well, THAT explains it!
>>>
>>> A wiki page is probably the best place for things like this  
>>> (that's where I found myself looking anyway...). That will allow  
>>> collaboration on working the document and getting things setup for  
>>> development.
>>>
>>> -David
>>>
>>>
>>> On May 13, 2009, at 2:14 PM, Adrian Crum wrote:
>>>
>>>> lol - that's what I was asking you. I have the document ready,  
>>>> where should I put it where everyone can find it? Do we want to  
>>>> create a Wiki page or Jira issue? I'm sure we will need some  
>>>> place to collaborate.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> David E Jones wrote:
>>>>> Okay, I give up trying to find it or a link to in my email  
>>>>> history... where is your document Adrian?
>>>>> -David
>>>>> On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
>>>>>> I have the design document ready, I just don't know what to do  
>>>>>> with it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> I think the sentiment in the thread is that more feedback  
>>>>>>> would be really helpful. It's kind of the lack of discussion  
>>>>>>> that seems to be holding this back.
>>>>>>> At this point I don't see any comments that argue against item  
>>>>>>> #4, so unless someone hops in with comments, issues, or  
>>>>>>> additional requirements then we'll just go with that.
>>>>>>> The next step, aside from the work that Adrian is doing, is to  
>>>>>>> get the data model going for this external configuration of  
>>>>>>> authorization that fits for this pattern and the requirements  
>>>>>>> in the other thread.
>>>>>>> -David
>>>>>>> On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
>>>>>>>> +1 - that's what I was saying - let's get back on this horse  
>>>>>>>> and make these improvements!  We all know it's sorely needed  
>>>>>>>> - don't let discussion stop us from making an impact.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Tim
>>>>>>>> --
>>>>>>>> Tim Ruppert
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>
>>>>>>>> o:801.649.6594
>>>>>>>> f:801.649.6595
>>>>>>>>
>>>>>>>> ----- "Adrian Crum" <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> I'm sure it is no surprise that I like the #4 design the  
>>>>>>>>> best - I
>>>>>>>>> think
>>>>>>>>> it matches the design I proposed.
>>>>>>>>>
>>>>>>>>> What IS surprising is the lack of response. We had a lively  
>>>>>>>>> discussion
>>>>>>>>>
>>>>>>>>> on the subject of security design a week ago, and now there  
>>>>>>>>> doesn't
>>>>>>>>> seem
>>>>>>>>> to be much interest in it.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David E Jones wrote:
>>>>>>>>>>
>>>>>>>>>> I haven't seen any additions to this original list in the  
>>>>>>>>>> attempt to
>>>>>>>>>
>>>>>>>>>> brainstorm, so I guess we're ready to start discussing the  
>>>>>>>>>> merits of
>>>>>>>>>
>>>>>>>>>> each of these approaches.
>>>>>>>>>>
>>>>>>>>>> Please comment!
>>>>>>>>>>
>>>>>>>>>> To get this started I'll express my opinions on the topic.  
>>>>>>>>>> In short,
>>>>>>>>> #4
>>>>>>>>>> is cool and 1-3 are crap. Is that biased enough for you?  
>>>>>>>>>> Well,
>>>>>>>>> here's
>>>>>>>>>> why I say that. Right now in order to configure permissions  
>>>>>>>>>> and
>>>>>>>>>> introduce more granular permissions as needed you have to  
>>>>>>>>>> edit some
>>>>>>>>> sort
>>>>>>>>>> of XML files (or in some case Java files or other things)  
>>>>>>>>>> possibly
>>>>>>>>>> including screen defs, service defs, and service  
>>>>>>>>>> implementations.
>>>>>>>>> The
>>>>>>>>>> most important part of point #4 is that authorization  
>>>>>>>>>> settings will
>>>>>>>>> be
>>>>>>>>>> totally external to these artifacts. In other words, the
>>>>>>>>> authorization
>>>>>>>>>> settings will refer to the various artifacts instead of the
>>>>>>>>> artifacts
>>>>>>>>>> pointing to the authorization settings.
>>>>>>>>>>
>>>>>>>>>> IMO that's the most important point: if security can't be  
>>>>>>>>>> configured
>>>>>>>>> by
>>>>>>>>>> an end-user and through run-time evaluated data (preferably  
>>>>>>>>>> in the
>>>>>>>>>> database so multiple app servers stay consistent, etc),  
>>>>>>>>>> then what's
>>>>>>>>> the
>>>>>>>>>> point? The security config in OFBiz would still be a large,
>>>>>>>>> expensive,
>>>>>>>>>> PITA.
>>>>>>>>>>
>>>>>>>>>> That said, other biased comments are now needed to balance  
>>>>>>>>>> the bias
>>>>>>>>> I
>>>>>>>>>> just threw into this... ;)
>>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On May 4, 2009, at 11:53 AM, David E Jones wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This thread is specifically for discussing possible  
>>>>>>>>>>> configuration
>>>>>>>>>>> patterns to use in OFBiz going forward. Please keep other
>>>>>>>>> discussion
>>>>>>>>>>> in another thread, including the merits of each  
>>>>>>>>>>> possibility...
>>>>>>>>> let's
>>>>>>>>>>> just brainstorm in this thread.
>>>>>>>>>>>
>>>>>>>>>>> To get things started, here are the patterns that have been
>>>>>>>>> discussed
>>>>>>>>>>> recently (in high level terms, we can get into  
>>>>>>>>>>> implementation and
>>>>>>>>>>> specific practices later on), these are in no particular  
>>>>>>>>>>> order:
>>>>>>>>>>>
>>>>>>>>>>> 1. artifacts responsible for their own security (especially
>>>>>>>>> services
>>>>>>>>>>> and screens), and security permissions are referred to  
>>>>>>>>>>> directly (ie
>>>>>>>>>
>>>>>>>>>>> the actual permissions are configured directly in the XML  
>>>>>>>>>>> tags for
>>>>>>>>> the
>>>>>>>>>>> artifact)
>>>>>>>>>>>
>>>>>>>>>>> 2. artifacts responsible for their own security, and no  
>>>>>>>>>>> direct
>>>>>>>>>>> references are used and instead an indirect security  
>>>>>>>>>>> control is
>>>>>>>>>>> referred to; this is basically the permission service  
>>>>>>>>>>> model we've
>>>>>>>>> been
>>>>>>>>>>> using where a permission service is basically a security  
>>>>>>>>>>> policy
>>>>>>>>> that
>>>>>>>>>>> refers to permissions, can query/filter/whatever to do  
>>>>>>>>>>> record level
>>>>>>>>>
>>>>>>>>>>> security, and in customization the permission service can be
>>>>>>>>>>> overridden or its function changed by ECA rules without  
>>>>>>>>>>> touching
>>>>>>>>> any
>>>>>>>>>>> OOTB code or configuration
>>>>>>>>>>>
>>>>>>>>>>> 3. a hybrid of #1 and #2 where artifacts refer directly to
>>>>>>>>> permissions
>>>>>>>>>>> and there is external configuration based on those  
>>>>>>>>>>> permissions that
>>>>>>>>>
>>>>>>>>>>> can add other qualifying permissions and/or invoke logic  
>>>>>>>>>>> to change
>>>>>>>>> how
>>>>>>>>>>> that permission is evaluated (ie override the default  
>>>>>>>>>>> behavior of
>>>>>>>>>>> requiring the user to have that permission and either add
>>>>>>>>> additional
>>>>>>>>>>> constraints or allow alternative constraints even if the  
>>>>>>>>>>> user does
>>>>>>>>> not
>>>>>>>>>>> have the original permission that triggered it all); this is
>>>>>>>>> recursive
>>>>>>>>>>> so that if an alternative permission is configured that  
>>>>>>>>>>> permission
>>>>>>>>> may
>>>>>>>>>>> also have further alternative permissions; also being  
>>>>>>>>>>> recursive if
>>>>>>>>>
>>>>>>>>>>> attached logic evaluates other permissions that may have
>>>>>>>>> alternative
>>>>>>>>>>> permissions and/or permission logic attached to them; as I
>>>>>>>>> understand
>>>>>>>>>>> what Andrew has implemented, this is the pattern he followed
>>>>>>>>>>>
>>>>>>>>>>> 4. artifacts are not responsible for their own security  
>>>>>>>>>>> except to
>>>>>>>>>>> specify whether any sort of permission is required or not  
>>>>>>>>>>> (ie a
>>>>>>>>>>> require-permission attribute, would be true by default;  
>>>>>>>>>>> for example
>>>>>>>>>
>>>>>>>>>>> most ecommerce screens would have this set to false); access
>>>>>>>>> control
>>>>>>>>>>> would be configured externally so that you can configure  
>>>>>>>>>>> access at
>>>>>>>>> the
>>>>>>>>>>> most granular level possible (we would go ALL the way here,
>>>>>>>>> including:
>>>>>>>>>>> screens, services, forms, form fields, menu items, tree  
>>>>>>>>>>> nodes, etc,
>>>>>>>>>
>>>>>>>>>>> etc); the access control tools would have patterns and  
>>>>>>>>>>> features to
>>>>>>>>>
>>>>>>>>>>> facilitate grouping of artifacts, grouping of users (ie  
>>>>>>>>>>> just use
>>>>>>>>> the
>>>>>>>>>>> current SecurityGroup entity), and support for both  
>>>>>>>>>>> functionality
>>>>>>>>>>> access and record-level access
>>>>>>>>>>>
>>>>>>>>>>> Can anyone thing of other patterns? Again, PLEASE do not  
>>>>>>>>>>> comment on
>>>>>>>>>
>>>>>>>>>>> which one you like better or what you think the advantages  
>>>>>>>>>>> or
>>>>>>>>>>> disadvantages are of each in this thread (of course,  
>>>>>>>>>>> definitely
>>>>>>>>> think
>>>>>>>>>>> about such things and feel free to comment in other  
>>>>>>>>>>> threads, I just
>>>>>>>>>
>>>>>>>>>>> want this to be a "hat's off" (yes, that is a reference to  
>>>>>>>>>>> Six
>>>>>>>>>>> Thinking Hats by Edward de Bono; anyone who hasn't read  
>>>>>>>>>>> that should
>>>>>>>>>
>>>>>>>>>>> give it a go!) brainstorming session.
>>>>>>>>>>>
>>>>>>>>>>> Thank You!
>>>>>>>>>>> -David
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Brainstorming: Security Configuration Patterns

Adrian Crum
David,

Thank you for the review and comments. Replies inline:

> 1. the hierarchy of artifacts should not be static as you have
> described; what we care about for access control is how an artifact is
> used, not where it is statically located; for example we don't care if
> the AcctgTransEntry entity is part of the accounting component, but we
> do care if it is used by service X or in screen Y or in webapp Z; in
> other words, the hierarchical description for the context of a resource
> isn't static, it is built up at run-time as things are being executed;
> this is a big problem with the current security stuff, and something
> Andrew started to address but that wasn't fully fleshed out

Hmmm... I thought it would make more sense the static way - from an
administrators perspective. The static method would make it easy to draw
up an administration screen where an administrator could pick a user,
pick an artifact, and then assign permissions to the artifact for that user.

It will be interesting to see how the dynamic way works out.

> 2. I don't like the idea of "User Group", "User Role" and "Policy"; it
> is confusing to have the multiple terms that mean slightly different
> things, and things that overlap in some ways with existing OFBiz
> concepts; I also don't think we need 2 levels of grouping between a user
> and what it has access to; in other words the current SecurityGroup that
> is used instead of referring directly to users is adequate as it takes
> care of not having to duplicate access control configuration for
> multiple users without adding too much complexity; I know this came from
> discussion in an email thread, but this seems to include every possible
> idea and try to make them fit together somehow instead of picking a
> single concept and making it work; in other words if someone is used to
> calling something a "role" or a "group" or a "policy" it won't make it
> any simpler if they get into the UI and all three are present and all
> three used in slightly different ways from what they are used to... the
> goal to make it easy for users of other systems to use it fails, and the
> goal to make it work well on its own also fails; hopefully this is okay,
> and I think so based on your comments in a blue info box about just
> using the User Groups (and hopefully I've expressed why I agree with
> that approach here)

I updated the page to suggest a single group as an alternative. But I'm
going to push hard for the idea that groups can be members of groups.
Maybe the implementation of that is a task I can tackle.

> 3. we should support services to check authorization and also support
> configuration of record-level permissions; in most cases these are
> really simple with just a view-entity that goes between the userLoginId
> or partyId and some other end-point, like a productId or a partyId, with
> specific constraints along the way (like a productCategoryI,
> productCategoryTypeId, roleTypeId, partyRelationshipTypeId, etc); for
> the most part I think we should try to eliminate the services that do
> permission checks and instead make it all configurable; also, if there
> is a service involved it should be referenced in the database-driven
> configuration and NOT in the artifact itself (again the goal is to get
> those out of the artifacts so that they are more readily and flexibly
> configurable)

I agree with you on the needs, and I thought I accommodated those needs
in the design, but perhaps I didn't make it clear. The approach I
proposed was to take the permission service declaration out of the
service definition and make it an assignable permission.

In the design, there are three types of security checks you can assign
to artifacts: 1. permission flags (the create, update, delete, etc like
we have now), 2. permission services (like the ones we have now that
check the user's relationship to data) that return access-granted or
access-denied), and 3. filter services - where data sets are filtered
based upon the user.

You can use the three types of security checks in any combination. I'm
pretty sure that will accommodate most scenarios.

I'll continue to build out the design page as I have time.

-Adrian
Reply | Threaded
Open this post in threaded view
|

Six Thinking Hats

Jacques Le Roux
Administrator
In reply to this post by David E Jones-3
From: "David E Jones" <[hidden email]>
> (yes, that is a reference to Six  
> Thinking Hats by Edward de Bono; anyone who hasn't read that should  
> give it a go!) brainstorming session.

Thanks David, I bought the book and just began to read it.
Very interesting, just the kind of tools I really missed!

Jacques

12