| Warning |
|---|
UNDER DEVELOPMENT |
Role-based access control is a common pattern in security, providing extensible role-specific behavior while retaining straightforward management. This module creates a standard API to assign and query roles on Fedora objects.
Objects do not have permissions specified in their properties; rather, objects have roles assigned, and then permissions are mapped onto roles elsewhere. This makes it much easier to manage permissions globally: rarely will masses of objects need to be updated if their permissions change. Only the role-to-permission mapping will be updated.Role-based access control is a common pattern in security, providing extensible role-specific behavior while retaining straightforward management. This module creates a standard API to assign and query roles on Fedora objects.
The module does not define the set of roles that may be assigned. If you choose to configure a set of supported roles, then the roles assigned via this API will be validated.
...
- Datastream 1 of object A only allows one principal to access the node: johndoe. He will have admin privileges. None of the ACLs on object A will be applied; the datastream will not inherit the EVERYONE => reader ACL on object A.
- Object R, a child of object Q, has its own content ACL: janedee has admin privileges on object R. No one else has any access to the node, not even the parent node (object Q) principals (EVERYONE and johndoe).
- Object T, a child of object B, has no content ACLs. So it inherits the ACLs of its most immediate ancestor with content ACLs: object B. EVERYONE has reader privileges on object T, and johndoe has admin privileges on the object.
- Object V also inherits the ACLs of object B (its most immediate ancestor with content ACLs).
- Object C has no content ACL; it inherits the ACLs of the root node, which is to say, nothing. No one other than fedoraAdmin has any access to this object.
Deletions
When deleting a node, the user must have an effective role that will allow them to delete ALL the descendant objects under the node (datastreams and child objects). If any descendant node cannot be deleted, then the entire delete transaction will be denied.
For example, in the graph shown above, the principal johndoe cannot delete object A, although he has an admin role on it and its datastream; that is because he does not have an effective role on object R, the node's grandchild, that will permit him to delete it. If he wants to delete object A, he will first have to ask janedee to delete object R.