Hi, Ideas:
1 - LDAP Secure Integration 2 - Implementation the Rest URL Secure ( LDAP based ). 3 - SOAP Header ( Service BUS Security concept ). 2009/5/5 Andrew Zeneski <andrew.zene...@hotwaxmedia.com> > Actually, SecurityGroup is a group that links permissions > (SecurityGroupPermission) which then get associated with UserLogins > (UserLoginSecurityGroup). In some systems a Role is a collection of > permissions, much like a SecurityGroup in OFBiz. > > > On May 5, 2009, at 2:26 PM, Harmeet Bedi wrote: > > 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 >>>> >>>> >>>> >>>> >>> >>> >>> >> >
