Access Control

Introduction

This document explains Daisy's features for access control: the authorisation of document operations such as read and write.

While we usually talk about documents, technically the access control happens on the document variant level: a user is granted or denied access to a certain document variant.

In many systems, access control is configured by having access control lists (ACLs) attached to documents. These ACLs contain access control rules which tell for a certain users or roles (groups) what operations they can or cannot perform.

For Daisy, it was considered to be too laborious to manage ACLs for each individual document. Therefore, there is one global ACL, where you can select sets of documents based on an expression and then define the access control rules that apply to these documents.

Structure of the ACL

The structure of the ACL is illustrated by the diagram below.

In ACL terminology, an object is the protected resource, and a subject is an entity wanting to perform an operation on the object. The objects in our case are documents, selected using an expression. The subjects are users, which can be living organisms, usually humans, or programs acting on behalve of them.

As will become clear when reading about the evaluation of the ACL below, the order of the entries in the ACL is important.

Object specification

The expression used to select documents in the object specification uses the same syntax as in the where clause of an expression in the Daisy Query Language. However, the number of identifiers that are available is severely limited. More specifically, you can test on the following things:

• the document type
• collection membership (using the InCollection function)
• document ID (to have rules specific to one document)
• fields for which the ACL-allowed flag of the field type is set to true
• the branch and language

Some examples of expressions:

InCollection('mycollection')

documentType = 'Navigation' and InCollection('mycollection')

$myfield = 'x' or $myotherfield = 'y'

For the evaluation of these expression, the data of the fields in the last version is used, not the data from the live version.

Access Control Entry

See diagram.

If the subject type is everyone, the subject value should be set to -1.

If you give 'read live' rights to someone, they are able to:

• read 'live data' of documents, this means: all non-versioned data, and the data from the live version.
  Access to retired documents is denied.
  Getting the list of versions of the document is not allowed.
  In query results, documents without a live version will not appear (if the option search_last_version is specified, documents only appear if the last version is the live version)
• add comments to documents

If you give 'read' rights to someone, they have full read access to the document (thus they can view all versions and the list of versions).

If you give 'write' rights to someone, they are able to:

• create documents
• update (save) documents
• take a lock on the documents

The 'delete' right gives users the possibility to delete documents or document variants.

If you give 'publish' rights to someone, they are able to change the publish/draft state of versions of documents.

Staging and Live ACL

In Daisy, there are two ACLs: a staging ACL and a live ACL. Only the staging ACL is directly editable. So it is required to first edit the staging ACL, and then put it live (= copying the staging ACL over the live ACL). It is possible to first test the staging ACL: you can give a document id, a role id and a user id and get the result of ACL evaluation in return, including an explanation of which ACL rules made the final decission. In the Daisy Wiki front end, all these operations are available from the administration screens. It is recommended that after editing the ACL, you first test it before putting it live, so that you are sure there are no syntax errors in the document selection expressions.

Evaluation of the ACL: how is determined if someone gets access to a document

The determination of the authorisation of the various operations for a certain document happens as follows:

1. If the user is acting in the role of Administrator, the user has read and write rights. The ACL is not checked.
2. If the user is owner of the document, the user has read and write rights (the ACL is not checked). Publish rights are determined by the ACL.
3. If the document is marked as private and the user is not the owner of the document, all rights are denied. The ACL is not checked.
4. The ACL result is initialised to deny all access (read live, read, write, publish and delete), and the ACL is evaluated from top to bottom:
• If an object expression evaluates to true for the document, the access control entries belonging to that object specification are checked
• If the subject type and subject value of an access control entry matches, the permissions defined in that entry override any previous result
• The evaluation of the ACL does not stop at the first matching object or subject, but goes further till the bottom.
5. At the end of the ACL evaluation some further checks are performed:
• if the user does not have 'read live' rights, any other rights are denied too
• if the user does not have read rights, the write and publish rights are denied too
• if the user does not have write rights, the delete right is denied too.

Further notes:

• when saving a document, the ACL is always checked on the document currently stored, not on the newly edited document (unless it is a new document). This is because the ACL evaluation result can depend on the value of fields, and the user might have edited those fields to try to gain access to the document.
• A user cannot change a document in such a way that the user itself has no write rights anymore to the document, e.g. by changing collection membership or field values.
• The ACL is only concerned with authorisation of rights on documents. Other permissions, like who can manage users, change the ACL, create document types, etc... is simply managed via the Administrator role: users acting in the Administrator role can do all those, others can't.

Other security aspects

This document only discussed authorisation of operations on documents for legitimate users. Other aspects of security include:

• authentication: see User Management
• audit logging: since Daisy generates JMS events for all (write) operations happening on the repository, you could get a full audit log by logging all these events. The content of these events are XML descriptions of the changes (usually an XML dump of the entity before and after modification)
• physical protection of the data: if someone can access the filesystem on which the parts are stored, or the relational database, they can see and/or modify anything
• integrity: hasn't anyone been altering the data before delivery to the user. Here the use of https can help.