Al,
How each network OS organizes LDAP objects and implements access to
those objects varies. I can only tell you how it works in NDS - I
haven't worked with Active Directory. I'll describe how NDS does things
and how I see OFBiz fitting in.
All network resources are objects. These include shared folders, shared
printers, servers, users, etc. All objects can have trustees assigned to
the object. A trustee is just another object. So, I could make the Jane
Smith user object a trustee of the Accounting Printer object - which
would grant Jane Smith access to the printer.
Objects can be grouped. So, instead of making Jane Smith the trustee of
Accounting Printer, I can have a group object called Accounting, make
the group a trustee of Accounting Printer, and put the Jane Smith object
in that group.
The Accounting group could also be a trustee of network folders that
people in accounting use, and other accounting-related network resources.
So, let's say I have an OFBiz object that contains other objects - one
for each OFBiz application. I can make the Accounting group a trustee of
the OFBiz Accounting object. Tah-dah! Jane Smith (and anyone else in
the Accounting group) has permission to use the OFBiz Accounting
application. The application is treated just like any other network
resource.
By the way, specific permissions are assigned in the trustee
relationship - supervisor, read, create, erase, modify, etc.
So, the OFBiz permissions and roles and such could be mapped fairly
easily into an NDS environment (using LDAP).
I'll leave it up to you to determine if it will work in your scenario.
Indeed, we will need a number of users to share their requirements so
that the implementation is as generic as possible.
-Adrian
Al Byers wrote:
Adrian,
This is good timing for me as I need to implement a security scheme in which
a user's ability to perform CRUD operations is dependent on their level
within an organization (ie. someone is a divisional supervisor so they can
only modify records within their division and its departments). Does this
functionality already exist? Something similar was done for content
management.
If this functionality were to be rolled into LDAP service, then I think the
LDAP would need to handle a person's party group role associations. It sort
of makes sense that if you want to manage a person's authentication outside
of OFBiz that you would want to manage their position/role assignments in
the same context since they are often related.
Going back to the integrated CRUD permission scheme, I am prepared to write
that if it is agreed that it is the right way to go. I would make the
assumption that permissions are always determined by where a person exists
in an organizational structure (but certain Security permissions would
override this contextual permission granting) - which is architected by
using the PartyRelationship entity and a person's role within that party
group (div, dept, etc.) I would like to see PartyRelationship used to
associate roles of a person with a party group because it can be time aware
and it can enforce some checks by use of the PartyRelationshipType.
In general, I am thinking that it would be something like a divisional
supervisor needing to approve Content published by a departmental worker.
The Content record would need to be tied to a department PartyGroup and the
divisional supervisor is able to edit or publish the content by virtue of
their hierarchical position and "ADMIN" role. In other cases, instead of a
Content entity, it may be the ContactMech for an employee or a purchase
order approval. In all these cases, the entity in question needs to be tied
to a PartyGroup structure and the permission to perform the operation would
be determined by the same method once it was.
In content permission granting there was the concept of "purpose". For
instance, a departmental supervisor may be able approve some content for
publication if its purpose was the weekly newsletter, but not if it were for
a corporate report.
-Al
