...

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, as either strings or URIs. When using URIs, it is necessary to translate the string-based username that is used for container-based authentication (i.e. Tomcat/Jetty authentication) into a URI. This is done by prefixing the string with a URI that is set in the container configuration: -Dfcrepo.auth.webac.userAgent.baseUri=http://example.org/user/ and/or -Dfcrepo.auth.webac.groupAgent.baseUri=http://example.org/group/

# as strings
<> acl:agent "obiwan", "yoda" .
 
# as URI references
<> acl:agent ex:obiwan, ex:yoda .

(Fedora Implementation Note: This is a slight departure from the W3C's description of WebAC, where the object of the acl:agent property must be a URI. We chose to implement it this way instead in such a way that the WebAC authorization module supports both String Literals and URIs in order to ease the integration of the WebAC authorization module with existing authentication or single-sign-on systems that identify users with string usernames. See ACL Agents - Strings vs. URIs for further details.)

However, listing individual users this way can get unwieldy, so you can also use the acl:agentClass property to specify a group of users:

...

# contents of </groups/jedi>, using strings to identify members:
<> a foaf:Group;
    foaf:member "obiwan";
    foaf:member "yoda";
    foaf:member "luke" .
 
# contents of </groups/jedi>, using URIs to identify members:
<> a foaf:Group;
    foaf:member ex:obiwan;
    foaf:member ex:yoda;
    foaf:member ex:luke .

(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 acl:agentClass property.)

...

If you use acl:accessTo to protect a container, that authorization rule by default will also apply to any of that container's children, unless that child has its own acl:accessControl property, as described below.

The second is to use the acl:accessToClass property to state that the authorization rule applies to any resource with the named RDF type:

...

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:

# </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.

...