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

« Previous Version 20 Next »

WebAC authorization Fedora module is an implementation of the still evolving draft by the W3C that proposes a decentralized authorization mechanism. See WebAccessControl specifications at the W3C website. 

W3C's definition of WebAccessControl

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. The ACL resource should specify the types of access, allowed users or groups, and applicable resources.

User -> Read/Write/Append/Control -> Resource/ResourceType

Example:

1. userA can Read document foo
@prefix acl: <http://www.w3.org/ns/auth/acl#>

</acls/read> acl:accessTo </foo> ;
acl:mode acl:Read;
acl:agent </agents/userA> .


2. users in NewsEditor group can Write to any resource of type News
@prefix acl: <http://www.w3.org/ns/auth/acl#>

</acls/write> acl:accessToClass </objecttype/news> ;
acl:mode acl:Read, acl:Write;
acl:agentClass </agents/newsEditor> .

 

Steps in determining the effective authorization

  1. Get the ACL of the requested resource.
    1.  if ACL exists:
      1. Find union of authorizations that specify access for the requesting user. This includes:
        1. authorizations that specify accessTo to the requested resource.
        2. authorizations that specify accessToClass of the requested resource type.
      2. Find union of authorizations that specify access for the requesting user's group. This includes:
        1. authorizations that specify accessTo to the requested resource.
        2. authorizations that specify accessToClass of the requested resource type.
      3. If authorizations exist for user or group:
        1. Find the union of authorizations found from steps 1.a.i and 1.a.ii.
        2. Go to step 4.
      4. if no authorization exist for user or group:
        1. Deny Access. Go to step 2.
    2. if no ACL exists for requested resource:
      1. Go to step 2.
  2. Get the ACL of the next ancestor (using either ldp:contains or fedora:hasParent).
    1.  if ACL exists:
      1. Find union of authorizations that specify access for the requesting user. This includes:
        1. authorizations that specify accessTo to the requested resource.
        2. authorizations that specify accessToClass of the requested resource type.
      2. Find union of authorizations that specify access for the requesting user's group. This includes:
        1. authorizations that specify accessTo to the requested resource.
        2. authorizations that specify accessToClass of the requested resource type.
      3. If authorizations exist for user or group:
        1. Find the union of authorizations found from steps 2.a.i and 2.a.ii.
        2. Go to step 4.
      4. Find union of authorizations that specify access for the requesting user. This includes:
        1. authorizations that specify accessTo to the requested resource's ancestor.
      5. Find union of authorizations that specify access for the requesting user's group. This includes:
        1. authorizations that specify accessToClass of to the requested resource's ancestor.
      6. If authorizations exist for user or group:
        1. Find the union of authorizations found from steps 2.a.iv and 1.a.v.
        2. Go to step 4.
      7. if no authorization exist for user or group:
        1. Deny Access. Go to step 2.
    2. if no ACL exists for the current ancestor resource:
      1. Go to step 2.
  3. If no more ancestor exist (root node reached) and no ACL or no matching authorization is found:
    1. Deny access.
  4. Use the most permissive from the set of authorizations found.
    1. Grant access if the authorizations permit requested access mode (read, write, append).
    2. Deny access if the authorizations does not permit requested access mode.

 

 

Example Request Authorization Flow

Gliffy Macro Error

An error occurred while rendering this diagram. Please contact your administrator.

  • Name: Fedora WebAC Request Authorization Flow

 

Example Scenarios

  1. 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.

    Acl.ttl
    <> a ???:WebAcl .
    
    Authorization.ttl
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .
    <> a acl:Authorization ;
       acl:agent "smith123" ;
       acl:mode acl:Read, acl:Write ;
       acl:accessTo <http://localhost:8080/rest/webacl_box1> .

    We would execute the following commands.

    > 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 INTO {
    <> acl:accessControl <http://localhost:8080/rest/acl> .
    }" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/webacl_box1"
  2. 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.

     

    Acl.ttl
    <> a ???:WebAcl .
    Authorization.ttl
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .
    <> a acl:Authorization ;
       acl:agent "Editors" ;
       acl:mode acl:Read, acl:Write ;
       acl:accessTo <http://localhost:8080/rest/box/bag/collection> .

    We would execute the following commands.

    > 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 INTO {
    <> 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"
  3.  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.

    Using the three "files" below to create our Authorization and ACL resources.

    Acl.ttl
    <> a ???:WebAcl .
    Auth_restricted.ttl
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .
    <> a acl:Authorization ;
       acl:agent "Restricted" ;
       acl:mode acl:Read ;
       acl:accessTo <http://localhost:8080/rest/dark/archive> .
    Auth_open.ttl
    @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.

    > 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 INTO {
    <> 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 INTO {
    <> 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"
  4. 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.

    Acl.ttl
    <> a ???:WebAcl .
    Auth1.ttl
    @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> .
    Auth2.ttl
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .
    <> a acl:Authorization ;
       acl:agent "Editors" ;
       acl:mode acl:Read, acl:Write ;
       acl:accessTo <http://localhost:8080/rest/public_collection> .

    I would execute the following code:

    > 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 INTO {
    <> acl:accessControl <http://localhost:8080/rest/acl> .
    }" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/public_collection"
  5. 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.

    Acl.ttl
    <> a ???:WebAcl .
    Auth_restricted.ttl
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .
    <> a acl:Authorization ;
       acl:agent 'Admins' ;
       acl:mode acl:Read ;
       acl:accessTo <http://localhost:8080/rest/mixedCollection> .
    Auth_open.ttl
    @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:

    > 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 INTO {
    <> acl:accessControl <http://localhost:8080/rest/acl> .
    }" | curl -X PATCH -H "Content-type: application/sparql-update" --upload-file - "http://localhost:8080/rest/mixedCollection"

 

  • No labels