In this quick start, you will use a Fedora 4 server with the WebAC Authorization module enabled to create a sample resource and an ACL for that resource, verify that access to that resource is correctly restricted, and finally modify the ACL to allow you to update the resource.
Prerequisites
- Fedora 4 with WebAC module enabled (you can use one of the pre-built WAR files from the fcrepo-webapp-plus project)a running Fedora repository
- curl
The commands in this guide assume that your Fedora 4 repository root is running at http://localhost:8080/fcrepo/rest.
Steps
Create these three files:
...
...
two files in a local directory:
Panel |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
<> dc:title "Hello, World!".
|
Panel |
---|
|
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
<><#authz> a acl:Authorization;
acl:accessTo </fcrepo/rest/foo>;
acl:agent "user1";
acl:mode acl:Read.
|
...
Upload these files into the repository:
Code Block |
---|
|
$ curl -X PUT http://localhost:8080/fcrepo/rest/aclfoo -u admin1:password3 \
-H "Content-Type: text/turtle" --data-binary @acl@foo.ttl
$ curl -X PUT http://localhost:8080/fcrepo/rest/foo -u admin1:password3 \
-H "Content-Type: text/turtle" --data-binary @foo.ttl \
-H 'Link: <http://localhost:8080/fcrepo/rest/acl>; rel="acl"'
$ curl -X PUT http://localhost:8080/fcrepo/rest/acl/authz -/fcr:acl -u admin1:password3 \
-H "Content-Type: text/turtle" --data-binary @authz@acl.ttl |
...
Now user1
is able to read the resource at http://localhost:8080/rest/foo
, but user2
cannot. To test this, try the following two commands:
Code Block |
---|
|
$ curl -i http://localhost:8080/fcrepo/rest/foo -u user1:password1
$ curl -i http://localhost:8080/fcrepo/rest/foo -u user2:password2 |
...
Panel |
---|
|
PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA {
<> dc:description "Quick Start with WebAC and Fedora 4" .
}
WHERE {}
|
Then run this to attempt to update foo
:
Code Block |
---|
|
$ curl -i -X PATCH http://localhost:8080/fcrepo/rest/foo -u user1:password1 \
-H "Content-Type: application/sparql-update" \
--data-binary @foo.sparql |
...
Panel |
---|
|
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
INSERT DATA {
<#authz> <> acl:mode acl:Write .
}
WHERE {}
|
Run this command to update the ACL authorization:
Code Block |
---|
|
$ curl -i -X PATCH http://localhost:8080/fcrepo/rest/acl/authz -u admin1:password3 \
-H "Content-Type: application/sparql-update" \
--data-binary @authz.sparql |
...
Now you should be able to re-run the earlier command to update the foo
resource as user1
:
Code Block |
---|
|
$ curl -i -X PATCH http://localhost:8080/fcrepo/rest/foo -u user1:password1 \
-H "Content-Type: application/sparql-update" \
--data-binary @foo.sparql |
Now this should return a 204 No Content response. To verify that the update happened, you can also go to http://localhost:8080/fcrepo/rest/foo in your web browser, and confirm that it has both dc:title and dc:description properties.
...
title | Access Control Link Header |
---|
When you perform a successful GET request on a resource that has an ACL associated with it (or with an ancestor), you will receive an additional header of the format.
Code Block |
---|
Link: <http://localhost:8080/fcrepo/rest/acl>; rel="acl" |
...
.
Note |
---|
title | ACLs for the Repository Root |
---|
|
When creating an ACL to protect the repository root, you must include a trailing slash in the Authorizations's acl:accessTo predicate, otherwise the Authorization will not match the request URI, and won't get applied.
Code Block |
---|
language | text |
---|
title | Non-Working Version |
---|
| <><#rootAuthz> a acl:Authorization;
acl:accessTo <https://localhost:8080/fcrepo/rest> . |
Code Block |
---|
language | text |
---|
title | Working Version |
---|
| <><#rootAuthz> a acl:Authorization;
acl:accessTo <https://localhost:8080/fcrepo/rest/> .
# note this trailing slash ---------------------^ |
|
...