+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" <adri...@hlmksw.com> 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 > >> > > > >
