VOStore interface

Paul Harrison pharriso at eso.org
Tue Aug 9 05:06:32 PDT 2005


Guy Rixon wrote:
> 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.
> 
>   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.
> 
> If you implement a store only for use from VOSpace then you naturally use
> the first model and do no per-user 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.

No - probably an easier-to-manage implementation would be to call out to 
  an "authorization" service - though there might be unacceptable 
performance problems with this.
> 
> 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.

OK - that is a feasible plan for a prototype, and I will do it..

> 
> 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 it is the simple case of a choice between

a) every authenticated user can do anything to any file
or
b) every authenticated user can do anything to any file that they own

then it is not too difficult to describe - however any shades between 
these two would be difficult.
> 
> 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 will try to implement a store that can be run in either mode, and it 
would be a working assumption that the authentication system is the 
same...;-)

Paul.

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


-- 
Paul Harrison
ESO Garching
www.eso.org



More information about the vospace mailing list