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" <adri...@hlmksw.com> To: dev@ofbiz.apache.org 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 >> > >
