To me this seemed to be intent from data model. - Group is PartyGroup that can be a collection of party through PartyRelationship. - PartyGroup is a Party. SecurityGroup can apply to Party hence to a PartyGroup - SecurityGroup is not a group of users, it is a role that applies to a Party.
On closer inspection that does seem to be the case. It seems that SecurityGroup is really a collection of user logins.. so not a role at all. I see your point.. inserting a SecurityRole entity between Group and Permission would be more flexible. In that case SecurityGroup is really a UserLoginGroup. Harmeet ----- Original Message ----- From: "Ruth Hoffman" <rhoff...@aesolves.com> To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 1:44:34 PM GMT -05:00 US/Canada Eastern Subject: Re: Brainstorming: Security Configuration Patterns Harmeet: Groups within OFBiz are similar to roles but in the RBAC model a "role" is an entity in and of itself. A group or collection of groups (also defined in RBAC as unique entities) may have one or more roles applied to them just as a user might. I think the value of RBAC is in its extensibility. For example, by defining "roles" we can abstract the definition of a permission (the security constraint in this case) away from the assignment of the permission. Just my 2 cents. Ruth > 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 >> >> >> > > >
