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

[Randy Letness]

Morgen Sagen wrote:
>
> Is a resource a collection?

A collection is a resource, but a resource may not be a collection.

>> 4. A User has access to multiple resources through ACLs
>> 5. Publishing an item to multiple collections requires a User principal.
>
> It's not immediately obvious to me that #5 needs to be a requirement, 
> but you must have a reason. :-)

The reason is that we want to move to a stricter security model, where a 
principal is granted access to resources through ACLs.  With true ACL 
support, cosmo will be able to do a lot more.   With multiple tickets, 
each ticket is essentially a principal with access to a single resource 
(most likely a collection).  It it much easier on the server side to 
deal with a single principal per request (either a ticket or user) 
because thats how the security model is structured today.  If a request 
includes multiple tickets, then that request is effectively 
authenticating as multiple principals (one for each ticket) and it 
becomes complex for the server to deal with multiple identities.  But if 
the request authenticates as a User, and the protocol includes hooks for 
granting access to resources using tickets, then tickets can be used to 
grant access to a resource.  This would be in place of the publisher 
explicitly granting access to the collection during publish, which would 
probably be something we want to add later.

>
> A while back I proposed having the client include all relevant tickets 
> when making a morsecode request:
>
>    http://tinyurl.com/2ptlmm
>
> Is your proposal a twist on mine except that the server *remembers* 
> what tickets are associated with a user's account?  Maybe you could 
> give some example scenarios and describe what gets sent back and forth.

Essentially a twist.  What would happen is that the server would examine 
all tickets included in the request and add the user to the ticket 
resource's ACL, effectivley giving the user access to the ticket's 
resource.  This happens before anything else, then when the security 
policy is applied (ACL of resources are checked), the user has access.

So for example:

1. User A publishes collection X, creates ticket T.
2. User B subscribes to collection X using T.
3. User B publishes collection Y.
4. User B adds item from X to Y
5. User B syncs Y

In Step 5, the client would authenticate as User B and include ticket T 
in the request.  When the server sees the ticket, it adds User B to the 
ACL of collection X and then processes the request normally.  When the 
server preforms authorization checks, the request completes successfully 
because User B was given access to collection X at the start of the 
request.  All subsequent requests wouldn't have to include the ticket 
for collection X.

Or another way it could happen, is the client could authenticate as User 
B and include ticket T as part of the subscription process to 
immediately grant User B access to X.

-Randy