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

[Morgen Sagen]

On Nov 7, 2007, at 10:09 AM, Randy Letness wrote:

> 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

Sorry I'm so late to respond.  I think I like this last suggestion  
about registering the ticket with the User account at subscription  
time, or at some point later if the user doesn't yet have a server  
account at the time a ticket is used by the client.  From then on, all  
syncs are done using user account info rather than sending tickets,  
right?

~morgen