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
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 >>
-- Paul Harrison ESO Garching www.eso.orgReceived on 2005-08-09Z14:06:46