5. Resource Authorization §  To configure access control restrictions, implementations MUST follow the recommendations of Web Access Control [SOLIDWEBAC] with the following additional requirements: acl:agentGroup appears to be implemented but it wasn't working for me (Danny Bernstein)- acl:default is not supported - currently behaves as "acl:default" exists without the acl:default defined.
-
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | FCREPO-2742 |
|---|
|
-
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | FCREPO-2743 |
|---|
|
-
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | FCREPO-2745 |
|---|
|
5.1 ACLs are LDP RDF Sources §- An ACL for a controlled resource on a conforming server MUST itself be an LDP-RS.
5.2 ACL Representation and Interpretation § (Danny Bernstein)- Implementations MUST inspect the ACL RDF for authorizations.
- Implementations MUST use only statements associated with an authorization in the ACL RDF to determine access,
- except in the case of
acl:agentGroup statements where the group listing document is dereferenced.
- The authorizations MUST be examined to see whether they grant the requested access to the controlled resource.
- If none of the authorizations grant the requested access then the request MUST be denied.
5.3 ACLs are discoverable via Link Headers §- A conforming server MUST advertise the individual resource ACL for every controlled resource in HTTP responses with a
rel="acl" link in the Link header, whether or not the ACL exists. - The ACL resource SHOULD be located in the same server as the controlled resource.
5.4 ACL linking on resource creation § A client HTTP POST or PUT request to create a new LDPR MAY include a rel="acl" link in the Link header referencing an existing LDP-RS to use as the ACL for the new LDPR.- The server MUST reject the request and respond with a 4xx or 5xx range status code, such as 409 (Conflict) if it isn't able to create the LDPR with the specified LDP-RS as the ACL.
- Assuming we will support the rel="acl" header on creation, this may be a non-issue.
- In that response, the restrictions causing the request to fail MUST be described in a resource indicated by a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header, following the pattern of [LDP] 4.2.1.6. - Some consensus on the notion that we will try to implement but if not enough time, we will fall back to rejection mode.
- This feature has been implemented but we may want to consider removing it based on SOLID requirements list in Section 5 (above)
5.5 Cross-Domain ACLs §- Implementations MAY restrict support for ACLs to local resources.
- Currently we allow users to insert remote acl URIs, but on retrieval, 500 error.
- If an implementation chooses to reject requests concerning remote ACLs,
5.6 Cross-Domain Group Listings § Implementations MAY restrict support for [SOLIDWEBAC] groups of agents to local Group Listing documents.- If an implementation chooses to reject requests concerning remote Group Listings,
- it MUST respond with a 4xx range status code
- and MUST advertise the restriction with a
rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header. - Consensus seems to be: agent groups must be internal to the repository.
 Do we need to perform any validation on the -Dfcrepo.auth.webac.userAgent.baseUri and fcrepo.auth.webac.groupAgent.baseUri to ensure these values do not cross domains?NB: Those values are used in the bodies of notifications. Are they used anywhere else? Or do fcrepo.auth.webac.groupAgent.baseUri values
5.7 Append Mode §- In the context of a Fedora implementation,
acl:Append should be understood as operations that only append, such as POSTing to a container, or performing a PATCH that only adds triples. - The Append mode is currently unimplemented.
5.7.1 LDP-RS §- When a client is allowed to perform
acl:Append operations on an LDP-RS:- A
DELETE request MUST be denied - A
PATCH request that deletes triples MUST be denied - A
PATCH request that only adds triples SHOULD be allowed - A
PUT request on an existing resource MUST be denied - A
PUT request to create a new resource MUST be allowed if the implementation supports creating resources using PUT (see: 3.6.3 Creating resources with HTTP PUT)
5.7.2 LDPC §- In addition to requirements in 5.7.1 LDP-RS, when a client is allowed to perform
acl:Append operations on an LDPC, a POST request MUST be allowed.
5.7.3 LDP-NR §- When a client is allowed to perform
acl:Append operations on an LDP-NR:- All
DELETE, POST, and PUT requests MUST be denied - A
PATCH request that deletes or modifies existing content MUST be denied - A
PATCH request that only adds content SHOULD be allowed- This one seems potentially complicated. How would we determine? If File A's bytes match first bytes of File A' ?
5.8 Access To Class §- Notwithstanding [SOLIDWEBAC]'s lack of support for it, the
acl:accessToClass predicate MUST be supported. - When an ACL includes an
acl:accessToClass statement, it gives access to all resources with the specified type, whether that type is client-managed or server-managed. - An implementation MAY use inference to infer types not present in a resource's triples or
rel="type" links in the Link header. Danny Bernstein: This functionality appears to be implemented but I could not get it to work. No errors just got a 403 when I was expecting a 200.
5.9 Inheritance and Default ACLs §- Inheritance of ACLs in Fedora implementations is defined by the [SOLIDWEBAC] ACL Inheritance Algorithm and MUST be reckoned along the [LDP] containment relationships linking controlled resources, with the following modification:
- In the case that the controlled resource is uncontained and has no ACL, or that there is no ACL at any point in the containment hierarchy of the controlled resource, then the server MUST supply a default ACL.
NB: acl:default rather than outdated acl:defaultForNew should be used.
- The default ACL resource SHOULD be located in the same server as the controlled resource.
- we will need to enforce this once acl:default is supported.
|