Ticket-Based Access Control in Cosmo
Ticket-Based Access Control Extension to WebDAV
defines extensions to WebDAV for transmitting a token or ticket
in the request to assign access privileges to a user otherwise unknown to the WebDAV server.
Cosmo's ticket support allows Chandler to provide a universal sharing feature. A Chandler user with a Cosmo account can share a calendar to the server and generate read-only and/or read-write tickets for the calendar. The user can then communicate the calendar's URL and a ticket to another person, who can then subscribe to the calendar even if he does not have an account on the Cosmo server. Cosmo tickets are not specific to Chandler; other clients can take advantage of Cosmo tickets to implement similar functionality.
Ticket Scope and Privileges
Tickets are inherited from ancestor resources. If a ticket is created on a resource, that ticket's id may be presented for that resource or any of its descendents to gain access as per the ticket's privileges.
For example, the ticket
is also honored for
. It is not honored for
The ticket specification defines two possible ticket privileges,
and DAV:write= as defined in WebDAV Access Control
defines a third privilege,
Tickets implicitly confer the
privilege defined by WebDAV Access Control. When using a ticket, a client can always use
to examine the
Cosmo implements the MKTICKET and DELTICKET methods defined in the ticket spec and makes the ticketdiscovery property available via PROPFIND (this property is protected).
Clients may as usual use an OPTIONS request to discover whether or not MKTICKET and DELTICKET are supported methods for a particular Cosmo URI. They may also examine the DAV response header for the string "ticket".
Due to interoperability concerns and the age of the specification, the XML content for a MKTICKET request looks slightly different than what's in the specification (see "Deviations from Spec" below for details).
The Cosmo version of the example from section 2.3 of the spec is:
MKTICKET /home/bcm/MyCalendar HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI=
<?xml version="1.0" encoding="utf-8" ?>
HTTP/1.0 200 OK
<?xml version="1.0" encoding="UTF-8"?>
Deviations from Spec
The Xythos ticket implementation differs from the specification in numerous ways. In order to promote interoperability, Cosmo aligns with Xythos as much as possible. There were also a few holes in the spec. The complete list of spec differences is as follows:
- Visit limits are not supported. Regardless of what is requested, Cosmo always returns a value of infinity. Xythos behaves the same way, and visit limits will likely be removed from future versions of the spec.
- The custom XML namespace
http://www.xythos.com/namespaces/StorageServer is used for XML elements defined by the spec (ticketdiscovery, ticketinfo, id and timeout).
- If different ticket ids are included in the request headers and URL, the id in the URL is used (the one from the Ticket header is ignored, even if the ticket identified by the URL is not found by the server).
- If a DELTICKET request is received for a resource on which the requesting user does not have appropriate access privileges, Cosmo returns a 403 (Forbidden) response. Example: User A owns resource X and creates ticket 123 on it. User B does not have privileges on resource X but attempts to delete the ticket.
- Similarly, only the owner of a ticket (the user who created it via MKTICKET) or a user with root privileges can delete it with DELTICKET.