In WebAC, an Authorization is a rule that describes who can access what, and how they can interact with the resource they can access. An Authorization is written as a series of RDF triples, with the Authorization resource as the subject for each of these triples. The Authorization resource URI is a hash URI, because of the requirement for potentially multiple, distinct Authorizations to be included in a single ACL resource. In this document, the subject <#authz> is used in the examples.
Prefixes used in this document:
...
| Code Block | ||
|---|---|---|
| ||
# as strings <><#authz> acl:agent "obiwan", "yoda" . # as URI references <><#authz> acl:agent ex:obiwan, ex:yoda . |
...
| Note |
|---|
...
Fedora Implementation Note: This is a slight departure from the |
...
SOLID WebAC spec, where the object of the |
...
. |
However, listing individual users this way can get unwieldy, so you can also use the acl:agentGroup property to specify a group of users:
| Code Block | ||
|---|---|---|
| ||
<><#authz> acl:agentGroup </groups/jedi> . |
...
| Code Block | ||
|---|---|---|
| ||
# contents of </groups/jedi>, using strings to identify members:
<> a vcard:Group;
vcard:hasMember "obiwan";
vcard:hasMember "yoda";
vcard:hasMember "luke" .
# contents of </groups/jedi>, using URIs to identify members:
<> a vcard:Group;
vcard:hasMember ex:obiwan;
vcard:hasMember ex:yoda;
vcard:hasMember ex:luke . |
...
| Note |
|---|
Fedora Implementation Note: As currently implemented, the group resource must also be stored in Fedora; there is no support for referencing external URIs with the |
...
"What?" - Resources and Resource Types
The next part of the authorization describes what resource can be accessed. As with the previous section on agents, there are also two ways to describe the resource. The first is to provide the URI to the resource using the acl:accessTo property:
| Code Block | ||
|---|---|---|
| ||
<><#authz> acl:accessTo </collections/rebels/plans> . |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<><#authz> acl:accessTo </collections/rebels> ; acl:default </collections/rebels> . |
The second is to use the acl:accessToClass property to state that the authorization rule applies to any resource with the named RDF type. For example, this authorization will apply to any pcdm:Container resources contained by /collections/rebels that do not have their own ACL:
| Code Block | ||
|---|---|---|
| ||
<><#authz> acl:accessToClass pcdm:Container ; acl:default </collections/rebels> |
...
Finally, an authorization states how the users or groups can interact with the resource or type of resource. This is known as the mode of access, and is specified using the acl:mode property. There are two predefined modes from the W3C's description of WebAC that Fedora understands: acl:Read and acl:Write. There are two additional access modes defined by the W3C document: acl:Control and acl:Append; however, they are not implemented in the fedora WebAC module.
Bringing it All Together
Here is a complete example of a WebAC ACL and its authorizations:
...
| language | text |
|---|
...
| Mode | Meaning | Allowed HTTP Requests |
|---|---|---|
acl:Read | read a resource |
|
acl:Write | write to a resource |
|
acl:Append | add to a resource |
|
acl:Control | read and write a resource's ACL |
|
...