Brainstorming: Security Configuration Patterns
Locked
12
12
Brainstorming: Security Configuration Patterns
 
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
In reply to this post by Adrian Crum
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 >>> >>> |
smime.p7s (3K)
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
In reply to this post by Adrian Crum
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 >>>>> >>>>> |
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
Re: Brainstorming: Security Configuration Patterns
|
|
| Free forum by Nabble | Edit this page |