Access Control

Access control means restricting access to resources. Access Control Lists (ACL) are typically lists of accounts, or principals, that are allowed to do something with a resource. Typically it is said that a principal has a set of privileges, or permissions, that it is allowed to do.

Chandler will need to deal with a variety of ACLs:

• iCalendar ACL-like features
• Repository ACL
• WebDAV ACL
• CalDAV ACL

The list above is from the least complex to the most complex feature set.

We also have:

• Tickets

which are less secure, light-weight way of doing WebDAV access control without requiring users to have accounts on the WebDAV server.

For completeness sake it should also be mentioned that Chandler will also need to deal with the system where it is installed, i.e. the operating system and local resources like the file system.

Terminology

• ACL = access control list consists of ACEs
• ACE = access control entry consists of the rules that define what someone is allowed to to
• principal = account = user (for our purposes)
• privilege = permission
• deny = forbid = restrict
• grant = allow
• resource = file, directory or other thing to which access is controlled by ACL

iCalendar ACL-like features

iCalendar supports PRIVATE, CONFIDENTIAL flags on components (events or tasks). Non-standard values are also possible. And in fact the iCal spec itself does not define what any of these values mean. And none of this will actually do anything without some additional machinery to tie in the users (principals) which is not specified in the iCal spec.

Question for design: what if we have an event marked PRIVATE but the user tries to grant read to public on that event?

Question: Any implementations that support this?

Discussion: Can we forget this, and use WebDAV/CalDAV ACL instead?

http://www.zvon.org/tmRFC/RFC2445/Output/index.html

Repository ACL

Chandler repository has had ACL implementation since the beginning of 2004. It has not been used, though.

The Chandler ACL model allows restricted access to items. The permissions are:

• DENY
• READ
• WRITE
• REMOVE
• CHANGE

If the DENY permission is set, access is denied even if some other permissions are also granted.

Because we have no current plans to use the repository in multi-user mode, there is no need to use the repository ACL for the time being.

WebDAV ACL

WebDAV adds the ACL property to resources. It can be queried using normal PROPFIND. Setting an ACL requires sending the ACL command where the body specifies the actual ACL to set.

WebDAV defines an ACL tree, but servers can customize the tree to make it both more fine grained and more granular.

The standard privileges are:

• read
• write-properties
• write-content
• write
  • implies write-properties
  • implies write-content
  • implies lock resource
• unlock
• read-acl
• read-current-user-privilege-set
• write-acl
• bind
• unbind
• all
  • implies all of the above privileges

Question: Why are bind and unbind not mentioned in Lisa's book?

A custom privilege could be defined like this:

• administer
  • implies read-acl
  • implies write-acl
  • implies read-current-user-privilege-set
  • implies unlock

These privileges can be granted and denied on a resource. The ACL evaluation happens in the same way as NFS version 4. ACEs are ordered, and as soon as the current request can be carried out with available provileges the ACL evaluation stops. Deny encountered along the way will naturally cause the request to fail.

The privileges are granted or denied for principles (users, accounts), which are simple resource themselves. The ACLs can be granted and denied based on the principal URLs. There are also shortcuts: the owner, all, authenticated and unauthenticated principals.

There are reports to find out the principals on a server and information about them.

WebDAV also supports group principals. While this adds flexibility and ease of maintenance, it also makes it harder to deal with ACLs. For example, the ACE for a principal is now not the complete truth about the privileges of said principal - the groups that the principal belongs to may have different ACEs.

Inherited ACLs add yet another wrinkle, and they are underspecified to such an extent that clients may not be able to figure out all inherited ACLs.

Question: Is this still the case.

http://zvon.org/tmRFC/RFC3744/Output/index.html

Some issues

• Which permissions would we support by showing in our GUI? What do we do when a resource has a permission granted or denied that's not one of the ones that we normally show in our GUI? E.g. we could decide that we make it easy to grant "write" permission by granting write-properties and write-content. But what do we do if we run across a resource that has write-properties but not write-content granted or vice versa?
  • Define the privileges we think match the 80-20 rule, and present a simple UI to do read, write ACL only. If the minimum privilege set not available on server, do not let the user specify. But would read all/deny all still be possible?
  • Geeky interface could show the whole ACL tree, which the user could enable/disable branches and leaves of.
• Another way we have been thinking to simplify is by administering ACLs on entire collections (shares) in one go. If we do that, then what does Chandler do when we encounter resources with more granular ACL settings?
• lock is not a privilege, but unlock is - somewhat confusing

Sample Alternate Support (Xythos)

Only four concrete privileges supported

• read
• write
  • groups unlock, write body, write properties, which you can't grant separately
• delete
• administer
  • groups read-acl, write-acl which you can't grant separately

How would we deal with this server if our GUI allowed the user to grant 'write-body'?

CalDAV ACL

CalDAV builds on top of WebDAV, so a CalDAV implementation must support WebDAV ACL as well. CalDAV defines read-free-busy additional privilege, and the full privilege tree now becomes:

• read
  • implies read-free-busy
• write-properties
• write-content
• write
  • implies write-properties
  • implies write-content
  • implies lock resource
• unlock
• read-acl
• read-current-user-privilege-set
• write-acl
• bind
• unbind
• all
  • implies all of the above privileges

http://ietfreport.isoc.org/all-ids/draft-dusseault-caldav-07.txt

Tickets

Sharing-0.6 design document defines support for tickets. In short, only MKTICKET request will be supported.

http://www.sharemation.com/%7Emilele/public/dav/draft-ito-dav-ticket-00.txt

Local ACLs

File system and so forth. Not relevant for sharing purposes.

WebDAV/CalDAV ACL implementat"> On WebDAV/CalDAV ACL implementation

Current implementation can parse the XML representing ACL, and build the ACL, ACE etc. objects to deal with Python. Serialization of these objects to XML also happens automatically. It is up to the higher level callers to decipher what the ACLs mean and how to change them.

Plan is to provide higher level API that understands the ACLs, which makes it possible to say "grant write access" even though the server has customized ACL. Or in other words, describe what a custom privilege means in terms of the standard privileges. However, if the server has customized ACL, granting write could end up granting more or less than the standard write.

The server is allowed to customize both the privileges and how the ACL request must be sent to be successful (allowed elements, order, etc.). It is possible to query for this information as well.

Parsing of the ACL XML is and will be lossy. That is, non-ACL stuff will be dropped when parsing, and other changes that are allowed by the XML specification, DTD and server can happen in roundtrip. If we discover buggy servers we may need to make attempts to preserve some markup, although it is notoriously difficult (think HTML/XML editors). WebDAV actually specifies that unknown elements must be dropped, including children.

Internationalization note: The ACL XML could contain international characters, even as custom privilege names, although the WebDAV spec seems to say it is not required to support intl element names.

Performance note: should piggypack and cache ACL-specific querying with other querying when possible. ACL stuff can get large, so that might be a limiting factor.

WebDAV/CalDAV ACLs"> Dealing with WebDAV/CalDAV ACLs

Some ACLs are inherited or protected, and can not be changed by clients. (Clients can not reliably know which it can change and which it can't without trying?)

MOVE preserves ACLs. COPY does not, so ACLs must be manually copied after COPY. In fact, any creation of a resource leaves ACL in an unknown state (from client's point of view) until queried.

It's best to LOCK before changing ACLs.

Privileges that are required for each method: method-privilege table.

Various ACL-specific reports.