Date: Fri, 29 Mar 2024 03:58:59 -0400 (EDT) Message-ID: <427325225.30036.1711699139595@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_30035_992447126.1711699139595" ------=_Part_30035_992447126.1711699139595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In WebAC, an Authorization is a rule that describes who can acce= ss what, and how they can interact with the resource they can access. An Au= thorization is written as a series of RDF triples, with the Authorization r= esource as the subject for each of these triples.
Prefixes used in this document:
@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 us=
ers using the acl:agent
property, as either strings or URIs. W=
hen using URIs, it is necessary to translate the string-based username that=
is used for container-based authentication (i.e. Tomcat/Jetty authenticati=
on) into a URI. This is done by prefixing the string with a URI that is set=
in the container configuration: -Dfcrepo.auth.webac.userAgent.b=
aseUri=3Dhttp://example.org/user/
and/or -Dfcrepo.au=
th.webac.groupAgent.baseUri=3Dhttp://example.org/group/
# as st= rings <> acl:agent "obiwan", "yoda" . # as URI references <> acl:agent ex:obiwan, ex:yoda .
(Fedora Implementation Note: This is a slight depar=
ture from the W3C's description of WebAC, where the object of the acl=
:agent
property must be a URI. We chose to implement it in such a wa=
y that the WebAC authorization module supports both String Literals and URI=
s in order to ease the integration with existing authentication or single-s=
ign-on systems that identify users with string usernames.)
However, listing individual users this way can get unwieldy, so you can =
also use the acl:agentClass
property to specify a group of use=
rs:
<>= ; 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:
# conte= nts 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 implement=
ed, the group resource must also be stored in Fedora; there is no support f=
or referencing external URIs with the acl:agentClass
property.=
)
The next part of the authorization describes what resource can be access=
ed. As with the previous section on agents, there are also two ways to desc=
ribe the resource. The first is to provide the URI to the resource using th=
e acl:accessTo
property:
<>= ; acl:accessTo </collections/rebels/plans> .
If you use acl:accessTo
to protect a container, that author=
ization 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 stat=
e that the authorization rule applies to any resource with the named RDF ty=
pe:
# 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 its=
elf that it is protected by the ACL that contains that authorization:
# </= 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> .
Finally, an authorization states how the users or groups can interact wi=
th the resource or type of resource. This is known as the mode of access, a=
nd is specified using the acl:mode
property. There are two pre=
defined 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
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 <> 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 resou= rce <> a ex:FlightPlan.