VOStore interface

[Reagan Moore]

Guy:
I agree that access needs to be authenticated to ensure that 
restricted operations such as writes are done by recognized users.


>Paul,
>
>we agree that access to a VOStore must be controlled, yes? Therefore, we have
>two possible cases:
>
>   1. A store owned by a VOSpace, where the VOSpace agent is the only allowed
>   user and call the store under its own, agent identity. This is the model
>   that Reagan is promoting and which is used in SRB. It's also the model in
>   AstroGrid MySpace to date.


Actually, VOSpace owns the data that is deposited into the store. 
VOSpace does not own the store.  Multiple VOSpace instances can 
deposit data into the same store under separate account identifiers.

The issue of authorization can then be handled separately by each 
VOSpace.  If VOSpace owns the data accessed through VOStore, VOSpace 
can manage the authorization, create access control lists for each 
file, and retrieve the data through a VOStore interface.  In this 
situation, VOStore provides a standard access mechanism for getting 
and putting files.


>
>   2. A store which accepts access authenticated to more than one identity.
>   Some of these identities could be used by user agents; some could be
>   services with delegated identities; some could be VOSpaces. This is the
>   model promoted by Wil (up to and at Kyoto) and, I think, by others in NVO.


This is the model used by the SRB.  The local store recognizes 
multiple accounts, one for each VOSpace instance.  The VOSpace 
instances can be federated to enable sharing of data that is stored 
under different VOSpace account IDs.

>
>If you implement a store only for use from VOSpace then you naturally use
>the first model and do no per-user authorization.

Even if a store is accessed by a single VOSpace instance, VOSpace can 
still authenticate each user, manage access controls for each file 
deposited in the store, and do per-user, per-file authorization.

>
>If you allow direct access to stores from DAL, then you have the second model
>by default and the stores _have_ to deal with file ownership. However, they
>don't _necessarily_ need tables of authorized users.


The standard example is GridFTP.  This utility runs at root, uses 
grid certificates to authenticate access, and then switches the 
execution of GridFTP to the user's account.  The challenge is that 
each store accessed this way has to have accounts for each user, and 
they can only see the data they personally own.  If they want to 
share data, the system administrator has to establish an account for 
the new user, and the owner of the data must set up access permission 
to the new user.

Direct access to stores makes it very difficult to share data.


>
>A minimal multi-user store allows any authenticated user to write data-items
>and tracks ownership; it has a metadatum stating ownership for
>each data-item. It doesn't check CRUD permissions; it assumes that the owner
>has full, implicit permission on all owned items. This is a lot easier than
>allowing variable permissions.


The SRB data grid typically gives permissions for all roles (read, 
write, annotate, create metadata, turn on audit trails) to the owner 
of the file.  Individual permissions can be established for other 
persons to access the data.


>
>I think Matthew is right. The authorization is an implementation issue. The
>tricky part is describing the authorization policy in the registration of the
>stores: something we haven't looked at so far.


If VOStore attempts to manage authorization, it will have to 
implement features similar to VOSpace.  VOStore would have to
authenticate the user
either check an access policy or ACL for each file
run as root to switch to the account of the person that owns the file

If the authorization is managed by VOSpace, VOStore can run as 
middleware, and not require root access.  I prefer to put the 
authorization software either in the local store, or in the VOSpace 
layer to avoid the need for VOStore to run as root.


>I suggest strongly that the same authentication system be used for both
>single-user and multi-user stores even though the authorization is different.
>This allows multi-user stores to be linked into VOSpace.

I agree.  (However I think of all stores as multi-user).

Reagan


>
>Cheers,
>Guy
>
>
>On Tue, 9 Aug 2005, Paul Harrison wrote:
>
>>  Matthew Graham wrote:
>>  > Hi,
>>  >
>>  > I would argue that this is an implementation issue: you have to make
>>  > sure that VOStore can fulfil what it promises.
>>  >
>>  > The required functionality for authentication is just that the VOStore
>>  > can recognise a valid message, e.g. the certificate used to sign the
>>  > SOAP message has the NVO CA in its certificate chain.
>>  >
>>
>>  This simple statement does hide some potentially complex implementation
>>  issues though...
>>
>>  - if the signing certificate is a user certificate, then is the VOStore
>>  expected to have a user database to manage the authorization issues
>>  (group access for instance)? I thought this was supposed to be delegated
>>  to the VOSpace level.
>>
>>  - Often the caller of a VOStore will be another service, requesting
>>  access on behalf of a user - so VOStore will be dealing with the GSI
>>  certificate proxy system at the first level
>>
>>
>>  Paul Harrison
>>
>
>Guy Rixon				        gtr at ast.cam.ac.uk
>Institute of Astronomy  	                Tel: +44-1223-337542
>Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523