Brainstorming: Security Configuration Patterns
Locked
12
12
Re: Brainstorming: Security Configuration Patterns
 
|
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 >>> >> > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 > |
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 >> > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >> > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 > >> > > > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>> >>> >>> |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>> >>>> >>>> > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>> >>>>> >>>>> |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>>> >>>>>> >>>>>> > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>>>> >>>>>>> >>>>>>> |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>>>>> >>>>>>>> >>>>>>>> > > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> > |
Re: Brainstorming: Security Configuration Patterns
|
|
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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> >>> |
Re: Brainstorming: Security Configuration Patterns
|
|
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 |
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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |