Vikas
On May 5, 2009, at 8:50 PM, Adrian Crum wrote:
Novell Netware has that, plus security groups. You can assign permissions to roles or groups, then assign the users to roles or groups.Another thing Netware has that might be useful - security equivalency. If two users require exactly the same sets of permissions, you don't have to assign those permissions twice. You assign permissions for one user, then make the second user "security equivalent" to the first.-Adrian Ruth Hoffman wrote:Hi All:One pattern I worked with some time ago is called Role Based Access Control (RBAC). This would be similar to #4 below, where you have a "role" - with permissions associated with that role - defining authorization levels. If you are interested in exploring this further, I'd be happy to elaborate.Ruth 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 configuration3. 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 followed4. 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 accessCan 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
smime.p7s
Description: S/MIME cryptographic signature
