Align Hydra's ACLs with Fedora's

[awead]

In order to let Fedora interpret and enforce the access controls that Hydra creates for resources, we need to have Hydra create ACLs that match up with Fedora.

1. Add rdf:Type acl:Authorization to all Hydra::AccessControls::Permission objects
2. Make explicit implied read and discovery permissions, so when a resource is editable by a user, there is only one triple that specifies write access, but there should be two additional triples for read and discovery because those rights are implicit with write access.
3. Use agentClass predicate, <http://www.w3.org/ns/auth/acl#agentClass>, for groups in instead of agent

[acoburn]

@awead can you clarify point 3 a bit? The Fedora impl uses acl:agent for user names and group names, e.g.:

<> a acl:Authorization ;
   acl:mode acl:Read ;
   acl:agent "repoEditorGroup", "user@institution.edu".

(Technically, the values for acl:agent should be URIs, but given our use cases and the practicality of implementing WebAC, we left this as string literals.)

The acl:agentClass can be for groups that are defined at a URI like so:

<> a acl:Authorization ;
   acl:mode acl:Read ;
   acl:agentClass </rest/groups/editors> .

Where </rest/groups/editors> is an in-domain URI that consists of a foaf:Group, defining a list of users. In principle, that URI could point to any resource on the web, but I had some significant security concerns about that (MITM attacks -- esp. arp poisoning attacks -- would make it an easy target), so in the Fedora impl, it must be an in-domain URI.

[awead]

@acoburn This is what resulted from @escowles and I looking into the issue, and he recommended the other predicate for groups, but I don't want to mis-represent him, so maybe he can weigh-in on this thread. Hydra is currently using group names as you describe above, that is, with acl:agent as either a string that identifies an individual or a group. So maybe that's the correct implementation after all and we don't need to change anything? I defer to either of you two on what's the best practice here!

[escowles]

@acoburn See https://jira.duraspace.org/browse/FCREPO-1895 for the Fedora ticket related to this. There were a few differences in how Fedora and Hydra Access Controls are creating ACLs, and these two tickets are intended to resolve those. @awead and I made the choices we did based on comparing the triples and a quick read of the WebAC wiki page -- and we're definitely open to changes.

For the agent, I think using repository-managed URIs is a reasonable default, both to avoid the security implications of fetching external data, and to provide a convenient place to describe the agent in the repository if that's desired. I agree that we're typically dealing with strings here, but making them URIs seems by prefixing them with a baseURI seems like the right thing to do here. It would be nice if there was some agreement on what those baseURIs should be (or to make them configurable so a user could point to external linked data sources if they had them and were comfortable with the security implications).

[acoburn]

@escowles I am totally open to making those agent values URIs. A system defined prefix wouldn't be too hard to implement for this. Do you have any suggestions for that?

[awead]

This 1b4b6351f78586d63b9c1eaeec5618ac48575455 addresses point 1. This 0eda8492156e8d32e8d2c3ff92a0a9a5094b5240 addresses point 2.

@acoburn, @escowles: What's the decision on point 3 above? Should any predicates be changed here?

[escowles]

@awead: Looking at the WebAC ontology, I think it's fine to use acl:agent for both users and groups. I think that acl:agentClass is intended for saying things like any user can access a resource (acl:agentClass foaf:Agent) or similar things. People could model their groups that way, but I think it's less likely than modeling them as foaf:Agent subclasses (Group, Project, etc.)

[awead]

Thanks, @escowles, I've struck it from the list of points. Are there any pertinent changes to Fedora that need to happen before we can test any of this?

[escowles]

The only change to Fedora is making the user/group values into URIs instead of strings -- there's a ticket for doing that https://jira.duraspace.org/browse/FCREPO-1895

[awoods]

The PR associated with https://jira.duraspace.org/browse/FCREPO-1895 is on hold for validation from a real use case. Would you ( @awead or @escowles ) be in a position to test against that PR?

[anarchivist]

Per discussion on Fedora IRC and Hydra Slack, #3 should be reinstated (somewhere) as:

3) Use agentGroup predicate, <http://www.w3.org/ns/auth/acl#agentGroup>, for groups in instead of agent

See https://jira.duraspace.org/browse/FCREPO-2275

[mohideen]

Any update on when would this effort to align to fedora-acl move forward? It this waiting on https://jira.duraspace.org/browse/FCREPO-2275