Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Warning
titleThis 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

Web Access Control (WebAC or WAC) is Fedora's system for authorizing requests for resources in the repository.

Table of Contents

...

Definitions

From the SOLID Web Access Control specification:

...

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.  

...

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
languagetext
titleAuthorization
@prefix acl: <http://www.w3.org/ns/auth/acl#>

<#auth1> a acl:Authorization .

...

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 be 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:

...

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

  1. The user userA can Read document foo

    Code Block
    languagetext
    @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" .


  2. Users in NewsEditor group can Write to any resource of type ex:News

    Code Block
    languagetext
    @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
    languagetext
    title/agents/NewsEditors
    @prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
    
    <> a vcard:Group;
        vcard:hasMember "editor1", "editor2".


  3. 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
    languagetext
    @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

Any resource in 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 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.

...

More Detailed Documentation

...