[Cosmo-dev] Re: securing access to items in multiple collections

Brian Moseley bcm at osafoundation.org
Fri Sep 28 14:19:18 PDT 2007

On 9/28/07, Morgen Sagen <morgen at osafoundation.org> wrote:

> - There are two collections on the server: A, B
> - An Item is in A
> - I am subscribed read-only to A, and read-write to B
> - In my client I copy the item from A to B
> - When I sync B I include in the HTTP headers the ticket-URLs for A
> and B (all collections I am subscribed to via ticket on this server)
> - Cosmo looks to see if the item exists on the server, and seeing that
> the item is in A examines the request headers for URLs matching
> collection A
> - Cosmo sees if that ticket for A is read-write, and since it isn't it
> rejects the request

i don't want to check access based on the happy accident that an item
happens to be a member of a particular collection *and* you've told me
that you have a ticket for that collection. that doesn't tell me
anything about the specific collection you copied the item from.

i think permissions should be based on the specific collection in
which you're interacting with an item, or in the case of republishing
a copied item, the specific source collection.

imagine an item that is a member of both of two subscribed collections
A and B. you have a read-only ticket for A and a read-write ticket for
B. you make a local collection C and drag the item from A to C. then
you publish C. which ticket should be examined - the A ticket or the B

with your proposal, the server would see that you've included ticket
urls for both collections A and B in the request, and it would have to
make a choice about which one it wants to use. you might argue that it
should choose the most tightly restrictive one, and that would work
out fine for my example above, but it wouldn't work if you had tried
to copy an item from collection B to C, because the most tightly
restrictive ticket, the read-only one for A, would deny the publish. i
can't think of any other rule that wouldn't cause a similar problem.

with my proposal, the server only has to check one ticket against one
collection - the source collection - so it never has to make any such

another benefit is that the credential, which is only valid in the
scope of a single item, is bundled inside the request payload with the
recordset for that item, so that the recordset can be processed by a
layer that is independent of the protocol processing layer.

it also removes any need to send tickets for published collections,
which is just plain wrong. a ticket is not a mechanism by which a
known user expresses to the server that he has permission to take an
action. tickets are only for anonymous access.

(here is where i make a tangential claim)

known users should only have to assert their identity to the server
(and have it confirmed). they should not have to assert anything about
what they are allowed to do, because that simply opens up
possibilities for exploits. the server should always know exactly what
operations are allowable simply by virtue of identifying a user. if a
known user wants to copy an item into a collection he has not
published, then we need to provide some way for the server to know
that the user has that permission without giving the user a ticket
(i.e, we provide a web ui for setting access controls and/or implement
the dav ACL method).

i've noticed a tendency to suggest things that abuse tickets simply
because the correct alternative (creating a real access control model
in the server) seems too scary. we need to stop this and get real
about securing our data. until we do that, while the server may be
interesting for some small number of people who are happy with our
current informality, it will only be a toy for a much broader group of
potential users.

More information about the cosmo-dev mailing list