Web Access Control (WebAC or WAC) is Fedora's system for authorizing requests for resources in the repository.
Definitions
From the SOLID Web Access Control specification:
Web Access Control (WAC) is a decentralized cross-domain access control system. The main concepts should be familiar to developers, as they are similar to access control schemes used in many file systems. It's concerned with giving access to agents (users, groups and more) to perform various kinds of operations (read, write, append, etc) on resources. WAC has several key features:
- The resources are identified by URLs, and can refer to any web documents or resources.
- It is declarative -- access control policies live in regular web documents, which can be exported/backed easily, using the same mechanism as you would for backing up the rest of your data.
- Users and groups are also identified by URLs (specifically, by WebIDs)
- It is cross-domain -- all of its components, such as resources, agent WebIDs, and even the documents containing the access control policies, can potentially reside on separate domains. In other words, you can give access to a resource on one site to users and groups hosted on another site.
WebAC enforces
Warning |
---|
title | This page is being updated |
---|
|
The examples on this page are incompatible with Fedora 5, as they do not follow the SOLID WebAC specification. This page is being updated to bring it into alignment with the current specification |
The Fedora WebAC authorization module is an implementation of the W3C's still evolving draft of an RDF-based decentralized authorization policy mechanism.
W3C's definition of WebAccessControl
From the WebAccessControl description at the W3C website:
WebAccessControl is a decentralized system for allowing different users and groups various forms of access to resources where users and groups are identified by HTTP URIs.
The WebAC module will enforce access control based on the Access Control List (ACL) RDF resource associated with the requested resource. In WebAC, an ACL consists of a set of Authorizations. Each Authorization is a single rule for access, such as "users alice and bob may write to resource foo", described with a set of RDF properties. Authorizations have the RDF type http://www.w3.org/ns/auth/acl#Authorization
.
For the remainder of this document, the http://www.w3.org/ns/auth/acl#
namespace will be abbreviated with the prefix acl:
.
Access Control Lists (ACLs)
An ACL is an RDF document (RDFSource) that contains WebAC statements that authorize access to repository resources. Each resource may have their own ACL, or implicitly be subject to the ACL of a parent container. The The location of the acl for a given resource may be discovered via a Link
header with relation rel=acl
.
Expand |
---|
title | For example, one might perform a HEAD request to discover the ACL location |
---|
|
$ curl -I http://localhost:8080/fcrepo/rest/myContainer
Date: Thu, 23 Aug 2018 14:46:46 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
ETag: W/"919bed096330d23b2e85c01d487758aa6bbf2dcb"
Last-Modified: Thu, 16 Aug 2018 18:49:54 GMT
Link: <http://www.w3.org/ns/ldp#Resource>;rel="type"
Link: <http://www.w3.org/ns/ldp#Container>;rel="type"
Link: <http://www.w3.org/ns/ldp#BasicContainer>;rel="type"
Link: <http://localhost:8080/fcrepo/rest/myContainer/fcr:acl>; rel="acl"
Preference-Applied: return=representation
Vary: Prefer
...
|
...
To create an ACL for a resource that does not already have one, a client needs to discover the ACL location (via HEAD
or GET
), then PUT
to that location.
Authorizations
Authorizations are the permissions statements contained within an ACL document. An ACL may should contain many authorizations, each of which must share the same subject. The way this is achieved is via hash URIsone or more authorizations. Each authorization should have a hash URI resource as its subject, and an rdf:type
of http://www.w3.org/ns/auth/acl#Authorization
:
Code Block |
---|
language | text |
---|
title | Authorization |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#>
<#auth1> a acl:Authorization . |
The properties that may be used on an acl:Authorization
are:
Property | Meaning |
---|
acl:accessTo |
the The URI of the protected resource. |
acl:accessToClass | An RDF class of protected resources. (While the WebAC specification does not support acl:accessToClass, servers are required to support it according to the Fedora specification) |
acl:agent |
the The user (in the W3C WebAC ontology, the user is named with a URI, but Fedora's implementation supports both URI- and string-based usernames) |
acl: |
modethe type of access (WebAC defines several modes: acl:Read , acl:Write , acl:Append , and acl:Control ; Fedora implements acl:Read and acl:Write ) | acl:accessToClass | an RDF class of protected resourcesagentClass | A class of agents, rather than a specific agent. Usage according to the WebAC specification is limited to foaf:Agent (meaning "everybody"), and acl:AuthenticatedAgent (meaning "any authenticated agent"). |
acl:agentGroup |
a A group of users (defined as |
a foafa vcard:Group resource listing its users with the |
foafmemberagentClassdefault | Signifies that an authorization for a container may be inherited by children of that container, if they do not otherwise define their own ACLs. |
acl:mode | The type of access (WebAC defines several modes: acl:Read , acl:Write , acl:Append , and acl:Control |
Identifies a class of agents, rather than a specific agent. Usage is limited to foaf:Agent (meaning "everybody"), and acl:AuthenticatedAgent (meaning "any authenticated agent"For a more detailed explanation of Authorizations and their properties, see WebAC Authorizations.
Agents
Agents are the users of Fedora. These identify the principals (in a security sense) that have made authenticated requests to the repository. In ACL Authorizations used by Fedora, these may be represented as strings or as URIs. The SOLID WebAC spec stipulates that agents are identified by URIs, and suggests (but does not have any normative language requiring) that these URIs are intended to be WebIDs. The Fedora specification does not comment on the topic of identifying agents. Nevertheless, for legacy purposes, the Fedora 5.x software allows strings or URIs to identify agents (e.g. "bob"
or <http://example.org/people/bob>
). When using URIs, there is no expectation by Fedora that these URIs be resolvable, or have a representation. It is highly recommended that you use URIs.
The mapping of a logged-on principal to a string or URI depends on the selection and configuration of a Principal Provider, which may provide the identity of users as strings or URIs depending on its implementation. Because agents are recommended to be represented as URIs, Fedora can be configured to automatically prefix any principals that are provided as strings with a baseURI. This is achieved by setting the system property fcrepo.auth.webac.userAgent.baseUri
. For example:
Code Block |
---|
language | text |
---|
title | agent prefix |
---|
|
fcrepo.auth.webac.userAgent.baseUri=http://example.org/agent/ |
Continuing with this example, if a user comes in as user "dra2"
, the user's identity will be converted to the URI http://example.org/agent/dra2 before applying ACLs.
Examples of Authorizations
The user userA can Read document foo
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#>
<#auth1> a acl:Authorization ;
acl:accessTo </fcrepo/rest/foo> ;
acl:mode acl:Read;
acl:agent "userA" . |
Users in NewsEditor group can Write to any resource of type ex:News
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix ex: <http://example.org/ns#> .
<#auth2> a acl:Authorization ;
acl:accessToClass ex:News ;
acl:mode acl:Read, acl:Write;
acl:agentClass </fcrepo/rest/agents/NewsEditors> . |
Code Block |
---|
language | text |
---|
title | /agents/NewsEditors |
---|
|
@prefix foafvcard: <http://xmlnswww.w3.comorg/foaf2006/0.1vcard/>ns#> .
<#auth3><> a foafvcard:Group;
foafvcard:memberhasMember "editor1", "editor2". |
The user userB can Read document foo (This involves setting a system property for the servlet container, e.g. -Dfcrepo.auth.webac.userAgent.baseUri=http://example.org/agents/)
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#>
<><#auth3> a acl:Authorization ;
acl:accessTo </fcrepo/rest/foo> ;
acl:mode acl:Read;
acl:agent <http://example.org/agents/userB> . |
Protecting Resources
A Any resource specifies the location of its ACL using the acl:accessControl
propertyin the repository may have its own ACL. The location of that (potential) ACL is given in a Link
HTTP header with rel="acl"
. If a resource itself does not specify an its own ACL, its parent containers are inspected, and the first specified ACL found is used as the ACL for the requested resource. If no ACLs are found, a filesystem-based ACL will be checked, the default policy of which is to deny access to the requested resource.
Example Scenarios
These scenarios assume that Fedora has been configured to use fcrepo.auth.webac.userAgent.baseUri=http://example.org/agent/ and fcrepo.auth.webac.groupAgent.baseUri=http://example.org/group/
I want to allow a user with username "smith123" to have read, write access to resource http://localhost:8080/rest/webacl_box1.
...
Using the two "files" below to create our Authorization and ACL resources.
Code Block |
---|
|
@prefix webac: <http://fedora.info/definitions/v4/webac#> .
<> a webac:Acl .
|
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
<> a acl:Authorization ;
acl:agent <http://example.org/agent/smith123> ;
acl:mode acl:Read, acl:Write ;
acl:accessTo <http://localhost:8080/rest/webacl_box1> . |
We would execute the following commands.
Code Block |
---|
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Authorization.ttl" "http://localhost:8080/rest/acl/auth1"
http://localhost:8080/rest/acl/auth1
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/webacl_box1" |
I want to let the group "Editors" have read, write access on all the items in the collection "http://localhost:8080/rest/box/bag/collection"
...
Using the two "files" below to create our Authorization and ACL resources.
Code Block |
---|
|
@prefix webac: <http://fedora.info/definitions/v4/webac#> .
<> a webac:Acl . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
<> a acl:Authorization ;
acl:agent <http://example.org/group/Editors> ;
acl:mode acl:Read, acl:Write ;
acl:accessTo <http://localhost:8080/rest/box/bag/collection> . |
We would execute the following commands.
Code Block |
---|
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Authorization.ttl" "http://localhost:8080/rest/acl/auth1"
http://localhost:8080/rest/acl/auth1
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/box/bag/collection" |
I would like the collection http://localhost:8080/rest/dark/archive to be viewable only by the groupId "Restricted", but I would like to allow anyone to view the resource http://localhost:8080/rest/dark/archive/sunshine.
The standard location for a resource's ACL is the fcr:acl
child of that resource, but clients should not rely on this behavior and always "follow their nose" by checking the Link
header.
...
Using the three "files" below to create our Authorization and ACL resources.
Code Block |
---|
|
@prefix webac: <http://fedora.info/definitions/v4/webac#> .
<> a webac:Acl . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
<> a acl:Authorization ;
acl:agent <http://example.org/group/Restricted> ;
acl:mode acl:Read ;
acl:accessTo <http://localhost:8080/rest/dark/archive> . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<> a acl:Authorization ;
acl:agent foaf:Agent ;
acl:mode acl:Read ;
acl:accessTo <http://localhost:8080/rest/dark/archive/sunshine> . |
The I would execute the following commands.
Code Block |
---|
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl_lock
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth_restricted.ttl" "http://localhost:8080/rest/acl_lock/auth1"
http://localhost:8080/rest/acl_lock/auth1
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl_lock> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/dark/archive"
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl_open
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth_open.ttl" "http://localhost:8080/rest/acl_open/auth2"
http://localhost:8080/rest/acl_open/auth2
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl_open> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/dark/archive/sunshine" |
The collection http://localhost:8080/rest/public_collection should be readable by anyone but only editable by users in the group Editors.
...
Using the three "files" below to create our Authorization and ACL resources.
Code Block |
---|
|
@prefix webac: <http://fedora.info/definitions/v4/webac#> .
<> a webac:Acl . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<> a acl:Authorization ;
acl:agent foaf:Agent ;
acl:mode acl:Read ;
acl:accessTo <http://localhost:8080/rest/public_collection> . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
<> a acl:Authorization ;
acl:agent <http://example.org/group/Editors> ;
acl:mode acl:Read, acl:Write ;
acl:accessTo <http://localhost:8080/rest/public_collection> . |
I would execute the following code:
Code Block |
---|
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth1.ttl" "http://localhost:8080/rest/acl/auth1"
http://localhost:8080/rest/acl/auth1
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth2.ttl" "http://localhost:8080/rest/acl/auth2"
http://localhost:8080/rest/acl/auth2
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/public_collection" |
Only the ex:publicImage type objects in the container http://localhost:8080/rest/mixedCollection are viewable by anyone, all others are only viewable by the group Admins.
...
Using the three "files" below to create our Authorization and ACL resources.
Code Block |
---|
|
@prefix webac: <http://fedora.info/definitions/v4/webac#> .
<> a webac:Acl . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
<> a acl:Authorization ;
acl:agent <http://example.org/group/Admins> ;
acl:mode acl:Read ;
acl:accessTo <http://localhost:8080/rest/mixedCollection> . |
Code Block |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<> a acl:Authorization ;
acl:agent foaf:Agent ;
acl:mode acl:Read ;
acl:accessToClass ex:publicImage . |
I would execute the following commands:
Code Block |
---|
> curl -X POST -H "Content-type: text/turtle" --data-binary "@Acl.ttl" "http://localhost:8080/rest"
http://localhost:8080/rest/acl
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth_restricted.ttl" "http://localhost:8080/rest/acl/auth1"
http://localhost:8080/rest/acl/auth1
> curl -X PUT -H "Content-type: text/turtle" --data-binary "@Auth_open.ttl" "http://localhost:8080/rest/acl/auth2"
http://localhost:8080/rest/acl/auth2
> echo "PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<> acl:accessControl <http://localhost:8080/rest/acl> .
}" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/mixedCollection" |
How-To Guides
More Detailed Documentation