VOStore interface

[Reagan Moore]

Guy:

>On Tue, 9 Aug 2005, Reagan Moore wrote:
>
>>  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.
>>  ...
>>  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.
>
>In that case you presumably have authorization in your store such that a
>VOSpace cannot access (or see) data-items owned by another VOSpace.


Yes.  It is possible to authorize access to data-items owned by 
another VOSpace instance.  What actually happens, is that a person 
with an account in VOSpace-a makes a request to VOSpace-b for access 
to a file.  VOSpace-b asks VOSpace-a to authenticate the user, then 
VOSpace-b checks its access controls for whether to provide the 
access, and if allowed retrieves the data on behalf of the user. 
Both VOSpace-a and VOSpace-b could be using the same store under 
different account IDs.



>
>>  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.
>
>Yes, but until VOSpace exists (propably not until the end of 2006), we need a
>way of using VOStores separately. Thus, we need both authentication and
>minimal authorization in the stores. I think we all agree that the
>mechanism needed to authenticate a space to a store will do to authenticate
>any other agent to the store. My point is that the minimal authorization
>policy - access by owner only - needed to allow spaces to share a store will
>also do _in the interim_ to allow other agents to share direct access to a
>store.


The Storage Resource Broker can be used today as a VOSpace 
implementation.  The SRB provides the authentication, authorization, 
name space management, replication, required for managing shared 
collections.

I would cast the problem differently, in terms of the usage 
paradigms.  I see a need for only two types of access:
- a researcher accesses personally owned data within a store.  In 
this case the store does the authorization.
- a researcher accesses data that is being shared through VOSpace. 
In this case VOSpace does the authorization.

I agree that there is no need to support sharing of personally owned 
data without going through VOSpace.  A purpose of VOSpace is to 
enable sharing of data.


>
>I agree that ACLs, user-settable permissions and data-sharing are better done
>through the VOSpace layer. Therefore, we leave them out of VOStore and specify
>the minimum that will allow stores to operate without spaces in 2005.
>
>>  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.
>
>Interesting, but not relevant, IMHO. We don't require users to have individual
>local accounts on the computers running the VOStores. In fact, we strongly
>require them _not_ to have such accounts; the management load on the sysadmins
>would be too high. Therefore, the FTP model does not apply. Instead, we need
>to track data-ownership in the service implementation, not in the account
>running the code.

I am beginning to understand your use case.  You want an individual 
to be able to store data at a remote collection without having an 
account on the remote system.  At the same time, you want the user to 
be authenticated, such that no-one else is allowed to access their 
data.  This is precisely what VOSpace (and the SRB implementation) 
provide.

The argument against this appears to be that you believe there is no 
viable implementation of VOSpace capabilities.  Please look at the UK 
e-Science grid use of the SRB as a data grid managing shared 
collections across stores.  The system is in production, with tens of 
terabytes of data collections being managed.  Larger production data 
grids exist, with collection sizes approaching a PB.


>
>>  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
>
>We already agreed that authentication code is needed anyway; it can be the
>same code whether or not we allow direct access to the store. Your email
>implies that we also need to enforce data ownership when spaces share a store,
>therefore we need minimal authorization code whether or not we allow direct
>access to the store.

Data ownership is important for projects that have not publicly 
released their data.  There are multiple levels of ownership:

- account under which the data is actually deposited on the local 
store.  This can be a VOSpace account
- access controls imposed by VOSpace to decide who is allowed to read 
the data that is stored in a VOSpace account.

In your system, some account is created at the local store to hold 
the data deposited through VOStore.  Authentication is done by 
VOStore, implying that VOStore has access to a catalog of allowed 
users.  Minimal authorization is done by VOStore such that the user 
can only see data that they have deposited.  This means that VOStore 
will have to maintain a catalog of all items written to the local 
store along with the identity of the person who wrote to the store. 
These two catalogs (user identities, ownership of data) are already 
maintained by VOSpace.

Do you plan that each VOStore implement a separate set of catalogs? 
You will then need to add VOStore operations to allow a person to 
check whether they may use a particular VOStore, and to request 
permission to use a store.  What administrative procedures will be 
supplied with VOStore to manage the requests for permission to use 
the resource?



>
>>  If the authorization is managed by VOSpace, VOStore can run as
>>  middleware, and not require root access.
>
>It can and it doesn't, regardless of whether VOSpace does the authorization.


So VOStore actually has an account ID under which it can deposit 
data, similar to the account ID that VOSpace would use.



>
>>  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.
>
>As argued above, some of the the permission checking has to happen inside the
>store, in order to keep multiple clients (spaces) in line. It doesn't matter
>whether this is done in the VOStore web-service or in the storage code that
>the web-service calls. You can implement the check in the storage code hidden
>behind the VOStore facade; another project can implement it in the web
>service.
>
>Remember, I'm not arguing for VOStore to have _permission-setting_ operations.
>I want the access permissions on stores to be basic, implicit and fixed. I
>expect all variable permissions, such as "write-protect this file" or "share
>this file with user-group x" to be handled in VOSpace _exactly as you have
>been advocating_. Yes, that means permission-checking in two places; no, that
>need not lead to bad performance; no, it won't be expensive to code.

Correct.  It means that management of the lists used to check 
permission will need to be done by both VOStore and VOspace.  I would 
greatly prefer an architecture in which VOSpace manages the lists and 
VOStore does not.

Reagan




>
>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