Page History

...

The module adds another REST endpoint to every Fedora Container and NonRdfSourceDescription resource path. The URL pattern is as follows:

...

root/  (default content roles, i.e. no roles for anyone)
├── Container A  (EVERYONE => reader; johndoe => admin)
│   ├── NonRdfSourceDescriptionBinary 1  (johndoe => admin)
│   └── Container Q  (EVERYONE => reader; johndoe => admin)
│       └── Container R (janedee => admin)    
├── Container B  (EVERYONE => reader; johndoe => admin)
│   └── Container T
│       └── Container V
└── Container C 

...

The following cases, based on the example data above, demonstrate how inheritance plays out.

1. NonRdfSourceDescription 1 Binary 1 of Container A only allows one principal to access the resource:  johndoe.  He will have admin privileges.  None of the ACLs on Container A will be applied; the NonRdfSourceDescription will binary will not inherit the EVERYONE => reader ACL on Container A.
2. Container R, a child of Container Q, has its own content ACL:  janedee has admin privileges on Container R.  No one else has any access to the resource, not even the parent resource (Container Q) principals (EVERYONE and johndoe).
3. Container T, a child of Container B, has no content ACLs.  So it inherits the ACLs of its most immediate ancestor with content ACLs:  Container B.  EVERYONE has reader privileges on Container T, and johndoe has admin privileges on the Container.
4. Container V also inherits the ACLs of Container B (its most immediate ancestor with content ACLs).
5. Container C has no content ACL;  it inherits the ACLs of the root resource, which is to say, nothing.  No one other than fedoraAdmin has any access to this Container.

...

When deleting a resource, the user must have an effective role that will allow them to delete ALL the descendant Containers under the resource. (NonRdfSourceDescriptionsbinaries, child Containers, etc..)  If any descendant resource cannot be deleted, then the entire delete transaction will be denied.

For example, in the graph shown above, the principal johndoe cannot delete container A, although he has an admin role on it and its NonRdfSourceDescriptionbinary;  that is because he does not have an effective role on Container R, the resource's grandchild, that will permit him to delete it.  If he wants to delete Container A, he will first have to ask janedee to delete Container R.

...

1. Unauthenticated user requests to see Container A.
   
   1. The user is assigned the user principal "EVERYONE".
   2. The authorization delegate intercepts the request, gets the ACLs for Container A:  "EVERYONE" => "reader" and "johndoe" => "admin".
   3. The authorization delegate compares the user principal "EVERYONE" to the principals in Container A's ACLs, and sees that "EVERYONE" matches.  The effective role for this request is "reader", the role paired with the principal "EVERYONE" on the Container.
   4. The authorization delegate sees if the role "reader" can view the Container;  it can.
   5. The authorization delegate returns "yes", and the request proceeds.
2. Unauthenticated user requests to see NonRdfSourceDescription 1 binary 1 on Container A.
   
   1. The user is assigned the user principal "EVERYONE".
   2. The authorization delegate intercepts the request, gets the ACLs for NonRdfSourceDescription 1binary 1: "johndoe" => "admin".
   3. The authorization delegate compares the user principal "EVERYONE" to the principals in NonRdfSourceDescription 1binary 1's ACLs, but does not find a match.
   4. The authorization delegate returns "no", and the request is denied.
3. Unauthenticated user requests to delete Container B.
   
   1. The user is assigned the user principal "EVERYONE".
   2. The authorization delegate intercepts the request, gets the ACLs for Container B:  "EVERYONE" => "reader" and "johndoe" => "admin".
   3. The authorization delegate compares the principal "EVERYONE" to the principals in Container B's ACLs, and sees that "EVERYONE" matches.  The effective role for this request is "reader", the role paired with the principal "EVERYONE" on the Container.
   4. The authorization delegate sees if the role "reader" can delete the Container;  it cannot.
   5. The authorization delegate returns "no", and the request is denied.
4. John Doe requests to update NonRdfSourceDescription 1 binary 1 on Container A.
   1. The user is assigned the user principals "johndoe" and "EVERYONE".
   2. The authorization delegate intercepts the request, gets the ACLs for NonRdfSourceDescription 1binary 1:  "johndoe" => "admin".
   3. The authorization delegate compares the user principals "johndoe" and "EVERYONE" to the principals in NonRdfSourceDescriptionbinary's ACLs, and sees that "johndoe" matches.  The effective role for this request is "admin", the role paired with the principal "johndoe" on the Container.
   4. The authorization delegate sees if the role "admin" can update the Container;  it can.
   5. The authorization delegate returns "yes", and the request proceeds.