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