r4 - 16 Jun 2009 - 01:21:30 - GrahamPerrinYou are here: OSAF >  Projects Web  >  CosmoHome > CosmoDevelopmentHome > CosmoTickets

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 123 created on /dav/bcm/Brian%20Moseley/ is also honored for /dav/bcm/Brian%20Moseley/Team_Meeting.ics and for /dav/bcm/Brian%20Moseley/attachments/agenda.doc. It is not honored for /dav/bcm/ or /dav/bcm/file.text.

The ticket specification defines two possible ticket privileges, DAV:read and DAV:write= as defined in WebDAV Access Control. CalDAV defines a third privilege, CALDAV:read-free-busy.

Tickets implicitly confer the DAV:read-current-user-privilege-set privilege defined by WebDAV Access Control. When using a ticket, a client can always use PROPFIND to examine the DAV:current-user-privilege-set and ticket:ticketdiscovery properties.

Request Methods

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:

  >>Request
  MKTICKET /home/bcm/MyCalendar HTTP/1.1
  Host: cosmo.osafoundation.org
  Content-length: xxx
  Content-Type: text/xml; charset="utf-8"
  Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI=
  <?xml version="1.0" encoding="utf-8" ?> 
  <ticket:ticketinfo xmlns:D="DAV:"
          xmlns:ticket="http://www.xythos.com/namespaces/StorageServer">
    <D:privilege><D:read/></D:privilege> 
    <ticket:timeout>Second-3600</ticket:timeout> 
  </ticket:ticketinfo>
  >>Response
  HTTP/1.0 200 OK
  Ticket: 266dxwmag0
  Content-Type: text/xml;charset=UTF-8
  Content-Length: xxx
  <?xml version="1.0" encoding="UTF-8"?>
  <D:prop xmlns:D="DAV:"
          xmlns:ticket="http://www.xythos.com/namespaces/StorageServer">
    <ticket:ticketdiscovery>
      <ticket:ticketinfo>
        <ticket:id>266dxwmag0</ticket:id>
        <D:owner>
          <D:href>http://localhost:8080/home/bcm/</D:href>
        </D:owner>
        <ticket:timeout>Second-3600</ticket:timeout>
        <ticket:visits>infinity</ticket:visits>
        <D:privilege>
          <D:read />
        </D:privilege>
      </ticket:ticketinfo>
    </ticket:ticketdiscovery>
  </D:prop>

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.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.