...
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/
Code Block | ||
---|---|---|
| ||
# 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:
...
Code Block | ||
---|---|---|
| ||
# 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.)
...
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. |
...