...
Prefixes used in this document:
| Code Block |
|---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix ex: <http://example.org/ns#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix pcdm: <http://pcdm.org/models#> .
@prefix webac: <http://fedora.info/definitions/v4/webac#> . |
...
The first part of the authorization describes who can access a resource. There are two ways to do this. The first is simply by naming particular users using the acl:agent property:
| Code Block |
|---|
|
<> acl:agent "obiwan", "yoda" . |
...
However, listing individual users this way can get unwieldy, so you can also use the acl:agentClass property to specify a group of users:
| Code Block |
|---|
|
<> acl:agentClass </groups/jedi> . |
The object of the acl:agentClass property must be a URI to a group resource (of type foaf:Group) containing a list of its members:
| Code Block |
|---|
|
# contents of </groups/jedi>:
<> a foaf:Group;
foaf:member "obiwan";
foaf:member "yoda";
foaf:member "luke". |
...
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 |
|---|
|
<> acl:accessTo </collections/rebels/plans> . |
...
The second is to use the acl:accessToClass property to state that the authorization rule applies to any resource with the named RDF type:
| Code Block |
|---|
|
# this will apply to any pcdm:Container resources
<> acl:accessToClass pcdm:Container . |
Note that adding acl:accessTo or acl:accessToClass to an authorization is only one half of what is required to protect a resource with a WebAC ACL. The other half is to specify on the resource itself that it is protected by the ACL that contains that authorization:
| Code Block |
|---|
|
# </acls/rebels>
<> a webac:Acl;
ldp:contains <commanders>.
# </acls/rebels/commanders>
<> a acl:Authorization;
acl:agentClass </groups/rebel-commanders>;
acl:accessTo </collections/rebels/plans>;
# modes will be discussed in the next section
acl:mode acl:Read, acl:Write.
# partial contents of </collections/rebels/plans>:
<> acl:accessControl </acls/rebels> . |
...
Here is a complete example of a WebAC ACL and its authorizations:
| Code Block |
|---|
|
# </acls/rebels>
<> a webac:Acl;
ldp:contains <commanders-plans>
ldp:contains <pilots-plans>;
ldp:contains <pilots-flight-plans>.
# </acls/rebels/commanders-plans>
# commanders...
<> a acl:Authorization;
# ...listed in this group...
acl:agentClass </groups/rebel-commanders>;
# ...have read-write access to...
acl:mode acl:Read, acl:Write;
# ...the plans
acl:accessTo </collections/rebels/plans>.
# </acls/rebels/pilots-plans>
# but pilots...
<> a acl:Authorization;
# ...listed in this group...
acl:agentClass </groups/rebel-pilots>;
# ...have read-only access to...
acl:mode acl:Read;
# ...the plans
acl:accessTo </collections/rebels/plans>.
# </acls/rebels/pilots-flight-plans>
# however, pilots...
<> a acl:Authorization;
# ...listed in this group...
acl:agentClass </groups/rebel-pilots>;
# ...do have read-write access to...
acl:mode acl:Read, acl:Write;
# ...their flight plan documents
acl:accessToClass ex:FlightPlan.
# </collections/rebels/plans>
# this resource is protected by the ACL at this URI
<> acl:accessControl </acls/rebels> .
# </collections/rebels/flights>
# this collection also specifies an ACL so all of its child resources will be
# covered by an ACL
<> a ldp:BasicContainer;
acl:accessControl </acls/rebels>;
ldp:contains <trench-run>.
# </collections/rebels/flights/trench-run>
# users in the group rebel-pilots will have read-write access to this resource
<> a ex:FlightPlan. |