VOStore interface

Matthew Graham mjg at cacr.caltech.edu
Wed Aug 3 11:01:41 PDT 2005


I think that most of what is VOStore and what is VOSpace is clear; 
however, the two grey areas are access control (authorization) and 
identifiers and this stems from the use case where the user wants direct 
access to a VOStore (e.g. a local store) and does not want to go through 
the VOSpace layer. Here are my suggestions for handling these areas:

Access control:

A VOStore can run in two modes: authorized and unauthorized. An 
unauthorized VOStore is semantically equivalent to an anonymous ftp 
site: any authenticated user (we still maintain security) can put 
something in, move/rename it, get it and delete it.
An authorized VOStore will only allow the requested operation if a valid 
authentication token is included in the request - all the VOStore has to 
do here is validate the authentication token. The generation of the 
authentication token is handled by VOSpace: it makes sure that the 
authenticated user has permission to do what they are requesting and if 
so, places a valid token in the request down to the VOStore.


The protocol identifier ivo:// identifies a resource that exists in the 
VO. It does not promise that you can completely resolve a URI beginning 
ivo:// in a registry, merely that some component of the URI will relate 
to a resource that has a registry entry, i.e. the bit before the first # 
can be resolved in a registry. So I can go to a registry and find out 
where ivo://nvo.caltech/vostores/vostore1 is
but I need to go to VOStore interface for this store to resolve 
ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need 
to introduce a second protocol just for VOStore contents.

Now resolution of individual VOStore identifiers has to be done at the 
VOStore level; however, VOSpace gives you the ability to set up a single 
logical identifier for multiple copies of the same resource so here we 
might want a separate protocol: vos and resolution of this identifier 
has to be done at the VOSpace level since VOSpace manages multiple VOStores.



Paul Harrison wrote:

> Reagan Moore wrote:
>> The differentiation between the VOStore and VOSpace interfaces is 
>> becoming unclear.  The latest draft implies that properties that were 
>> originally associated with VOSpace would now be supported by VOStore.
> I have to say that I agree that there seems to be some confusion in 
> this area - with hindsight it was probably a mistake to defer the 
> specification of VOSpace and work on VOStore alone as the "easier" 
> problem - the specifications should be worked in tandem to see where 
> it is most appropriate to place roles and responsibilities for 
> particular use cases, so that a "global" solution is arrived at.
> I thought that the original separation into VOStore and VOSpace was 
> done so that VOStore could be an essentially "dumb" BLOB repository 
> that did what it was told by the VOStore layer when it comes to issues 
> of file permissions and hierarchical file names. However, because no 
> VOSpace specification was created, these more advanced features have 
> crept into the VOStore layer.
>> Let's look at the current VOStore and VOSpace proposal:
>> VOStore                                     VOSpace
>> Storage of objects                          management of virtual 
>> file system
>> data stored under unspecified ID?
>> no user home directory                      User home directory
>> directory hierarchy                         Directory hierarchy
>> Unique file name within storage             User-defined file names
>>                                             Mapping VOSpace name to 
>> VOStore name
>>                                             List files for user
>> Restrict access by user identity?
>> Identify files with URIs
>> Access controls on local file name          Access controls on 
>> VOSPace name
>> This characterization mixes name space, mixes access controls, does 
>> not provide consistent identity, does not allow consistent 
>> management.  For instance, if a URI is being provided for file 
>> identity within the VOStore interface, then there is no need for 
>> user-specified names within VOSTore.  A second issue is the 
>> assumption that file access can be restricted by user identity.  This 
>> means that the VOStore must manage the owner for each file, access 
>> controls for each file.  File systems usually do this by creating 
>> accounts for each user name and applying Unix permissions.  Is this 
>> capability to be provided now by both VOSpace and VOStore?  We need a 
>> cleaner separation of capabilities.
> This security aspect is crucial - it is clear that the owners of 
> VOStores would not want to be managing user identity lists of all the 
> VObs users at their stores - the fine grained access controls should 
> be at the VOSpace level. If VOStores only respond to requests from 
> trusted VOSpace services then this is possible, but I think that the 
> perceived requirement for more detailed access control in the VOSpace 
> layer has come about because prototype end-user applications have 
> appeared that talk directly to the VOStore layer - of course, it is 
> not surprising that this has happened because there was no VOSpace 
> definition for the end user applications to talk to.
> How file/BLOB identity is managed is also crucial to producing a 
> system that offers more than ftp. I thought that one of the 
> fundamental driving  use cases for a VOSpace was that the same BLOB 
> could potentially live on serveral VOStores, and that when specifying 
> a resource in VOSpace, in a workflow for instance, the resource could 
> be retrieved from the VOStore that was "closest" on the network to 
> where the resource would be consumed. This sort of use case does 
> require some careful thought about the allocation and management of 
> identifiers, and I think probably means that the VOStore will have to 
> be aware of the VOSpace identifier.
> I also have an issue with reusing ivo: as the protocol part for the 
> URI of an identifier in this system - ivo: is already well defined and 
> used as the identifer for registry entries, and the "protocol" for 
> accessing the entity associated with the identifier is defined in the 
> registry interface standard. This means that given an identifier of 
> the form ivo://authority.org/something#blah a software agent (or human 
> for that matter) cannot tell by inspection whether the identifier 
> refers to a file in VOSpace or is simply a reference to a registry 
> entry (e.g. for a SkyNode) - this leads to software having to be more 
> complex in order constantly to test for the different possibilities. I 
> think that it would be better to have a URI with a different protocol 
> part, vos: for instance, it would then be immediately apparent that 
> the VOSpace protocol should be used to access the entity referred to 
> by the identifier.
>> Let's look at the Storage Resource Broker data grid separation of 
>> local storage management from the virtual file system management:
>> Local storage system                        SRB name space
>> Storage of objects                          management of virtual 
>> file system
>> data stored under SRB ID
>> no user home directory                      User home directory
>> directory indirection structure             Directory hierarchy
>> Unique file name within storage             User-defined file names
>>                                             Mapping SRB name to local 
>> file name
>>                                             List files for user
>> Access through SRB ID, controlled by SRB
>>                                             Identify files by URIs
>>                                             Access controls on SRB name
> I think that as Regan points out the separation of responsibilities 
> that  SRB has with the local storage system is pretty much the right 
> model for  VOSpace and VOStore - though it means that SRB is pretty 
> much at VOSpace level rather than a VOStore as is suggested in the 
> current VOSpace definition document.

More information about the vospace mailing list