I guess what Adrian described is user A Alias to user B. Personally I don't think it's necessary at the very beginning.
在 2009-05-06三的 10:17 +0530，Vikas Mayur写道： > Hi Adrian, > > Is it desirable behavior? What if both the user need to have different > permission at certain point of time. > > Lets take a simple example of Jira. Two person contributing in OFBiz > have an account on jira with same and very basic permission. At this > moment they did not see any option to assign a task. > > Later on one becomes a committer and now this person have higher > permissions (obviously see an option to assign a task) then the other > person. Does this mean second person should also be granted the same > permission as of the first at this moment, IMO No. > > This could be desirable behavior in certain cases but I am not able to > think of any example. > > Vikas > > On May 5, 2009, at 10:39 PM, Adrian Crum wrote: > > > Yes. > > > > -Adrian > > > > Vikas Mayur wrote: > >> In security equivalency, what would happen if the permission for > >> first user are changed? Does these permission are also applied to > >> second user? > >> 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 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 > >>>>> > >>>>> >
