Archived

If you are looking for the last documentation in the 4.x series, see 4.7.5. Looking for another version? See all documentation.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Quick Start with WebAC

In this quick start, you will build and run a Fedora 4 server with the WebAC Authorization module enabled, 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

  • Java 8
  • Maven
  • Git
  • curl

Steps

Clone the fcrepo-webapp-plus repository, build it, and start the server:

$ git clone https://github.com/fcrepo4-exts/fcrepo-webapp-plus.git
$ cd webapp-plus
$ mvn install jetty:run -Pwebac

Create these three files:

acl.ttl
@prefix webac: <http://fedora.info/definitions/v4/webac#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<> a webac:Acl, ldp:BasicContainer.
foo.ttl
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a ldp:BasicContainer;
   acl:accessControl </rest/acl>;
   dc:title "Hello, World!".
authz.ttl
@prefix acl: <http://www.w3.org/ns/auth/acl#>.

<> a acl:Authorization;
   acl:accessTo <http://localhost:8080/rest/foo>;
   acl:agent "user1";
   acl:mode acl:Read.

Upload these files into the repository:

$ curl -X PUT http://localhost:8080/rest/acl -u admin1:password3 \
    -H "Content-Type: text/turtle" --data-binary @acl.ttl
$ curl -X PUT http://localhost:8080/rest/foo -u admin1:password3 \
    -H "Content-Type: text/turtle" --data-binary @foo.ttl
$ curl -X PUT http://localhost:8080/rest/acl/authz -u admin1:password3 \
    -H "Content-Type: text/turtle" --data-binary @authz.ttl

(Note: The order you upload these in is important, since foo references acl, and authz references foo.)

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:

$ curl -i http://localhost:8080/rest/foo -u user1:password1
$ curl -i http://localhost:8080/rest/foo -u user2:password2

The first request should succeed with a 200 OK response code, and the second should fail with a 403 Forbidden.

To demonstrate that user1 indeed only has read-only access to foo, we can try updating foo. Create a file named foo.sparql with the following contents:

foo.sparql
PREFIX dc: <http://purl.org/dc/elements/1.1/>

INSERT {
    <> dc:description "Quick Start with WebAC and Fedora 4".
}
WHERE {}

Then run this to attempt to update foo:

$ curl -i -X PATCH http://localhost:8080/rest/foo -u user1:password1 \
      -H "Content-Type: application/sparql-update" \
      --data-binary @foo.sparql

This request should fail with a 403 Forbidden response, since user1 has read-only access to foo. To add write access for user1, we will need to update the acl/authz resource as admin. Create a file named authz.sparql with the following contents:

authz.sparql
PREFIX acl: <http://www.w3.org/ns/auth/acl#>

INSERT {
    <> acl:mode acl:Write .
}
WHERE {}

Run this command to update the ACL authorization:

$ curl -i -X PATCH http://localhost:8080/rest/acl/authz -u admin1:password3 \
      -H "Content-Type: application/sparql-update" \
      --data-binary @authz.sparql
If the update to the authorization was successful, you will see a 204 No Content response.

Now you should be able to re-run the earlier command to update the foo resource as user1:

$ curl -i -X PATCH http://localhost:8080/rest/foo -u user1:password1 \
      -H "Content-Type: application/sparql-update" \
      --data-binary @foo.sparql

Now this should return a 204 No Content responses. To verify that the update happened, you can also go to http://localhost:8080/rest/foo in your web browser, and confirm that it has both dc:title and dc:description properties.

  • No labels