Skip to content

Authorization

Jump to bottom
Aaron Coburn edited this page May 26, 2020 · 8 revisions

Trellis uses WebAC for resource authorization. A subset of WebAC has been defined by the Solid project in the form of a WebAC specification. It is that specification that has informed the Trellis implementation of WebAC.

It is possible to turn WebAC enforcement on or off with a runtime configuration value.

Agents as IRIs

The first requirement of WebAC is that agents be represented as IRIs, specifically WebIDs. This is a good practice that extends beyond the scope of Solid, Trellis and WebAC. All Trellis Authorization mechanisms result in user principals being represented as WebIDs, so this first requirement is easily satisfied.

WebAC Authorization resources

Each Trellis resource has its own acl resource. Clients should use the typical LDP discovery mechanism by following link headers to find it:

Link: <https://example.org/container/resource?ext=acl>; rel="acl"

For a resource at https://example.org/container/resource, that resource would be https://example.org/container/resource?ext=acl. This resource may or may not exist. If it doesn't exist, the WebAC enforcement algorithm will look for an ACL resource in some parent resource until it reaches a partition's root resource.

Sometimes it is useful for a client to know the location of this "effective" ACL resource. That location can be found with a link header:

Link: <https://example.org/container/?ext=acl>; rel="http://www.trellisldp.org/ns/trellis#effectiveAcl"

When WebAC is in effect, that ?ext=acl resource can only be accessed or modified if the given user agent has the acl:Control privilege on the resource. If so, an acl:Authorization statement can be added to the resource:

@prefix acl: <http://www.w3.org/ns/auth/acl#>.

<#authorization> a acl:Authorization ;
    acl:mode acl:Read, acl:Write ;
    acl:accessTo <https://example.org/container/resource> ;
    acl:agent <https://example.org/users/1>, <https://example.org/users/2> .

This will give https://example.org/users/1 and https://example.org/users/2 read and write access to the resource at https://example.org/container/resource. Those users, however, will not be able to modify the ACL resource itself, since they lack the acl:Control mode.

The other possible acl mode is acl:Append, which is somewhat like acl:Write except that, in the case of Trellis, it only allows the addition of Containment or Membership triples to that resource. For instance, it would allow a user to POST to a container but not modify the user-managed properties of that container or delete other child resources.

Public access

It is possible to make a resource publicly accessible by adding the triple <> acl:agentClass foaf:Agent to an Authorization statement. For example:

@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<#authorization> a acl:Authorization;
    acl:agentClass foaf:Agent;  # everyone
    acl:mode acl:Read;  # has Read-only access
    acl:accessTo <https://example.org/container/resource> . # the resource

Default Authorization statement

Trellis will generate a default Authorization statement for the root resource. This statement provides Read, Write and Control access to all users. One should plan to modify this configuration when first setting up a Trellis server.

Unsupported features of WebAC

Following the Solid WebAC specification recommendation, Trellis does not support acl:accessToClass, Regular Expressions in statements such as acl:agentClass or a strict notion of resource ownership.

Clone this wiki locally