-
Notifications
You must be signed in to change notification settings - Fork 41
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
Comments
@awead can you clarify point 3 a bit? The Fedora impl uses
(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
Where |
@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! |
@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). |
@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: 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.) |
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? |
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 |
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? |
Per discussion on Fedora IRC and Hydra Slack, #3 should be reinstated (somewhere) as:
|
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 |
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.
Use agentClass predicate,<http://www.w3.org/ns/auth/acl#agentClass>
, for groups in instead of agentThe text was updated successfully, but these errors were encountered: