Those ideas might be good to add to the related thread - "Brainstorming:
Security Requirements/Scenarios"
-Adrian
Rodrigo Lima wrote:
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
