Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align Hydra's ACLs with Fedora's #313

Open
awead opened this issue Feb 5, 2016 · 11 comments
Open

Align Hydra's ACLs with Fedora's #313

awead opened this issue Feb 5, 2016 · 11 comments

Comments

@awead
Copy link
Contributor

awead commented Feb 5, 2016

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
Copy link

acoburn commented Feb 5, 2016

@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
Copy link
Contributor Author

awead commented Feb 6, 2016

@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
Copy link
Contributor

escowles commented Feb 6, 2016

@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
Copy link

acoburn commented Feb 6, 2016

@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
Copy link
Contributor Author

awead commented Feb 8, 2016

This 1b4b635 addresses point 1.
This 0eda849 addresses point 2.

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

@escowles
Copy link
Contributor

escowles commented Feb 8, 2016

@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
Copy link
Contributor Author

awead commented Feb 8, 2016

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
Copy link
Contributor

escowles commented Feb 8, 2016

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
Copy link

awoods commented Apr 29, 2016

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
Copy link

anarchivist commented Oct 18, 2016

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

  1. 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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

6 participants