13.1 What Is Access Control?

The most basic form of access control, found in almost all file systems, is a way to grant a long-term privilege to access a resource to a user or group. That description can be taken as the problem statement for WebDAV access control. Let's look at each part of this problem statement and the features commonly or rarely found in existing repositories, particularly file systems.

Access is granted to resources in the repository. If a file exists named index.html, it's generally possible to grant privileges specifically for index.html. When the resource is a directory, the privileges may also apply to resources inside the directory. Granularity to the level of properties, however, is rare. The server enforces access control for all resources in the repository.

Access to resources is granted to users or groups. Access control information must identify users and groups in order for the server to grant permission to the specified principals. The server must be able to authenticate users and know enough about group membership to decide whether to grant access based on group membership.

Roles and certificates are advanced authorization features not commonly seen in shared file systems.

Authentication

User authentication is typically handled separately from access control. WebDAV supports the HTTP user authentication mechanisms [RFC2617]. Both standard HTTP mechanisms offer a way to identify the user (with a user name and optionally a realm). The access control specification assumes that the server has some way to authenticate users and uniquely identify them, although this may be some nonstandard mechanism such as NTLM authentication for HTTP or session cookies.

Let's see what information a simple ACL contains in a quick example before proceeding. Assume there is a group called hr-group with members Alice, Bob, and Carl. The access control information for index.html includes the following permissions and ownership:

 Grant administer to the owner Grant write to hr-group Grant read to all The owner is Alice 

With this list of permissions, a write operation with authentication from Alice, Bob, or Carl will be allowed, but not from any other user. Alice owns and thus can administer the resource, although we're not yet sure what that might mean. The all user is not a real user, it's a special principal name that encompasses any user (sometimes called "public" or "guest"). Thus, the server will allow read requests from any user, with or without authentication.

Locks and Access Control

WebDAV locks can be likened to a temporary revocation of write permission for all users except the lock owner. Although locks do cause write operations to be forbidden, this comparison fails to describe important parts of lock functionality.

• Locks are held not just by a user but also by a specific WebDAV client process. The lock protects the document from other software authenticated as the same user.

• You can lock a resource, change its permissions, and unlock it again, since locking and access control are independent. In fact, I recommend locking resources while changing permissions.

• Locks time out.

• Locks identify who is currently changing the resource and hopefully even what client software package holds the lock. In contrast, write permission may be granted to many principals who may not currently be editing the resource.

13.1.1 Access Control Model

The access control model for WebDAV resources was very consciously derived from existing file system practice, with slight adaptations to handle properties.

Access is divided into several well-defined privileges. The most common privileges are the right to read a file and the right to write it (change or update it). Other possible privileges are:

• The ability to delete the resource (may be covered by the write privilege)

• The ability to read properties or metadata (may be covered by the read privilege)

• The ability to write properties or metadata (may be covered by the write privilege)

• The ability to read the ACL

• The ability to alter the ACL

• The ability to view the contents if the resource is a collection (sometimes this is covered by the read privilege)

When a privilege is not granted to a user (directly or as a member of a group), that type of operation is not allowed.

A resource may have an owner who is treated specially for access control. The owner of the file can have irrevocable privileges, such as the privilege to change access control settings. If all privileges could be taken away from everybody, the resource could be put into a state where nobody can do anything on it, including changing privileges. If the owner has the irrevocable privilege to set access control, then the owner can always fix up the resource and grant privileges to those who should have them.

Each resource has one ACL. (The acronym ACL, pronounced "ackle," is also used to refer to the functionality provided by access control in general.) The ACL contains a number of ACEs. On simple systems, a resource's ACL contains all the privilege information relating to that resource.

Each access control entry identifies a single principal. A principal can be a named user or a named group (a group is a collection of named users). The principal can also be a special kind of role or characteristic identifier such as all users or all authenticated users. Each entry in an ACL names a principal using a principal ID.

Within an ACE, multiple privileges can be granted or denied to a single identified principal. That means that each principal named in the access control list must have its own entry. For example, if read access on index.html is granted to "all" and write access is granted to "hr-group," this must be two access control entries, which together form an ACL.