| Warning | ||
|---|---|---|
| ||
The examples on this page are incompatible with Fedora 5, as they do not follow the SOLID WebAC specification. This page is being updated to bring it into alignment with the current specification |
The Fedora WebAC authorization module is an implementation of the W3C's still evolving draft of an RDF-based decentralized authorization policy mechanism.
...
For the remainder of this document, the http://www.w3.org/ns/auth/acl# namespace will be abbreviated with the prefix acl:.
Authorizations
Access Control Lists (ACLs)
An ACL is an RDF document (RDFSource) that contains WebAC statements that authorize access to repository resources. Each resource may have their own ACL, or implicitly be subject to the ACL of a parent container. The location of the acl for a given resource may be discovered via a Link header with relation rel=acl.
| Expand | ||
|---|---|---|
| ||
|
If a resource does not have an individual ACL (and therefore relies on an implicit ACL from a parent), this link header will still be present, but will return a 404. This is because the location of ACLs is solely determined by the server, much like the automatically-created LDP-RS descriptions for binary resources. The key difference is that Fedora does not create ACLs automatically, only their location.
Therefore, to discover whether a resource has an individual ACL, a client would need to:
- Perform a
HEADorGETagainst the resource, - Find the link header
- Do a
GETorHEADagainst the ACL location, and see if returns 200 or 404.
To create an ACL for a resource that does not already have one, a client needs to discover the ACL location (via HEAD or GET), then PUT to that location.
Authorizations
Authorizations are the permissions statements contained within an ACL document. An ACL may contain many authorizations, each of which must share the same subject. The way this is achieved is via hash URIs:
| Code Block | ||||
|---|---|---|---|---|
| ||||
@prefix acl: <http://www.w3.org/ns/auth/acl#>
<#auth1> a acl:Authorization . |
The properties that The properties that may be used on an acl:Authorization are:
| Property | Meaning |
|---|---|
acl:accessTo | the URI of the protected resource |
acl:agent | the user (in the W3C WebAC ontology, the user is named with a URI, but Fedora's implementation supports both URI- and string-based usernames) |
acl:mode | the type of access (WebAC defines several modes: acl:Read, acl:Write, acl:Append, and acl:Control; Fedora implements acl:Read and acl:Write) |
acl:accessToClass | an RDF class of protected resources |
acl:agentClassagentGroup | a group of users (defined as a foaf:Group resource listing its users with the foaf:member property)the foaf:member property) |
acl:agentClass | Identifies a class of agents, rather than a specific agent. Usage is limited to foaf:Agent (meaning "everybody"), and acl:AuthenticatedAgent (meaning "any authenticated agent"). |
For a more detailed explanation of Authorizations and their properties, see WebAC Authorizations.
...
The user userA can Read document foo
Code Block language text @prefix acl: <http://www.w3.org/ns/auth/acl#> <><#auth1> a acl:Authorization ; acl:accessTo </foo> ; acl:mode acl:Read; acl:agent "userA" .
Users in NewsEditor group can Write to any resource of type ex:News
Code Block language text @prefix acl: <http://www.w3.org/ns/auth/acl#> . @prefix ex: <http://example.org/ns#> . <><#auth2> a acl:Authorization ; acl:accessToClass ex:News ; acl:mode acl:Read, acl:Write; acl:agentClass </agents/NewsEditor>NewsEditors> .
Code Block language text title /agents/NewsEditors @prefix foaf: <http://xmlns.com/foaf/0.1/> . <><#auth3> a foaf:Group; foaf:member "editor1", "editor2".
The user userB can Read document foo (This involves setting a system property for the servlet container, e.g.
-Dfcrepo.auth.webac.userAgent.baseUri=http://example.org/agents/)Code Block language text @prefix acl: <http://www.w3.org/ns/auth/acl#> <> a acl:Authorization ; acl:accessTo </foo> ; acl:mode acl:Read; acl:agent <http://example.org/agents/userB> .
Storing WebAC ACLs in Fedora 4
...
:Read; acl:agent <http://example.org/agents/userB> .
Protecting Resources
A resource specifies the location of its ACL using the acl:accessControl property. If a resource itself does not specify an ACL, its parent containers are inspected, and the first specified ACL found is used as the ACL for the requested resource. If no ACLs are found, a filesystem-based ACL will be checked, the default policy of which is to deny access to the requested resource.
...