Under WebAC, with a non-administrative user, the linked Hydra::AccessControl result in 403s for subsequent requests.

[mikedurbin]

This issue cannot be demonstrated or resolved until the following two issues are corrected in Fedora4.
https://jira.duraspace.org/browse/FCREPO-2024
https://jira.duraspace.org/browse/FCREPO-2027

Background:
The goal is to run hydra in such a way that it may only make changes within a single container within the repository and is prevented (by fedora's web-ac authorization module) from making changes outside of that space. To be clear, the scope of this particular issue is support that scenario, which is a necessary prerequisite for having hydra's access controls be fully enforced by the repository.

Repository Setup:
Running a version of Fedora 4 (not yet released) that contains the two fixes above with webac authorization enabled, I created a resource "/fcrepo/rest/libra2" for which the user "libra2" was granted read and write permission using WebAC. (https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorization+Delegate) I then asked the developers on that hydra head to point their sufia instance to that container using the non-admin "libra2" user and report success or failure.

The access logs looked liked this:
libra2 [24/May/2016:09:01:45 -0400] "PUT /fcrepo/rest/libra2/dev/8g/84/mm/24/8g84mm241 HTTP/1.1" 201 85
libra2 [24/May/2016:09:01:45 -0400] "HEAD /fcrepo/rest/libra2/dev/8g/84/mm/24/8g84mm241 HTTP/1.1" 403 -

This shows the libra2 user PUT a resource and then was subsequently denied all access to it.

In looking at the resource (as an administrative user) the issue was that it was linked to an acl (with the acl: accessControl) predicate) that didn't have a contained authorization for the libra2 user. It would be sufficient if:

1. The Hydra::AcessControl resource had the type "http://fedora.info/definitions/v4/webac#Acl" (though the current fedora 4 WebAC implementation doesn't seem to enforce this yet)
2. that same resource contain (ldp:contains) an authorization that grants read and write permission to the given resource to the user that hydra uses to access the repository (in our case, "libra2"). Something like this:

 @prefix acl: <http://www.w3.org/ns/auth/acl#>
<> a acl:Authorization ;
    acl:accessTo </fcrepo/rest/libra2/dev/8g/84/mm/24/8g84mm241> ;
    acl:mode acl:Read, acl:Write;
    acl:agent "libra2" .

[jcoyne]

I'd say that this is also going to be an issue: https://jira.duraspace.org/browse/FCREPO-1895

[acoburn]

Just a point of clarification: the webac:Acl type (i.e. on the parent of the acl:Authorization nodes) isn't strictly necessary. At least, the Fedora WebAC module doesn't require it. That is, given this structure:

</rest/some/object> a fedora:Resource, pcdm:Object ;
    acl:accessControl </rest/acl/public> .

</rest/acl/public> a fedora:Resource, webac:Acl .

</rest/acl/public/auth1> a fedora:Resource, acl:Authorization ;
    acl:accessToClass fedora:Resource ;
    acl:mode acl:Read ;
    acl:agent foaf:Agent .

The </rest/acl/public> a webac:Acl triple can safely be omitted. Some people (myself included) think that the webac:Acl type makes the repository object structure easier to understand, but it certainly is not necessary from the perspective of Fedora. That said, the object in that position MUST contain (ldp:contains) children with the type acl:Authorization.

[mikedurbin]

Alright, https://jira.duraspace.org/browse/FCREPO-1895 is closed, so all we need it to create a compatible acl:Authorization and then hydra can ship with a fedora that uses WEB AC which would resolve this issue and put us in good shape towards issue 313... which I acknowledge is a superset of this issue and I probably shouldn't have made this one.