+1. That's why I mentioned OU. An OU can be a path not only String, for example /root/domain1/Administrators/.
在 2009-05-05二的 11:52 -0400，Harmeet Bedi写道： > I think an important thing missing is parentId in SecurityGroup. > Adding that would give you heirarchy. Groups sort of are roles. Group has > association with Subject(UserLogin through UserLoginSecurityGroup), > Permission(SecurityGroupPermission), Permission is tied implicitly to action > and resource.. Sort of RBAC. > > Harmeet > > ----- Original Message ----- > From: "Ruth Hoffman" <rhoff...@aesolves.com> > To: dev@ofbiz.apache.org > Sent: Tuesday, May 5, 2009 11:05:12 AM GMT -05:00 US/Canada Eastern > Subject: Re: Brainstorming: Security Configuration Patterns > > 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 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 > > > > >
