r6 - 16 Nov 2005 - 19:06:38 - DaveMorrisYou are here: TWiki > 
Astrogrid Web > DaveMorris > VoSpaceAdopt
Astrogrid Web > DaveMorris > VoSpaceAdoptVoSpace? adopt
Ideas and use cases for adopting and changing ownership of files in VoStore? and VoSpace? services. Author- DaveMorris - 15 Nov 2005
- GuyRixon
- Matthew Graham (Caltech)
- PaulHarrison (ESO)
Use cases
Adopting file into VoSpace?
There are several cases where a user may want to import a file directly into a local VoStore?, and then want to 'adopt' it into their VoSpace?. The simplest case is where a user wants to use a GUI or command line tool to import a file into a local VoStore?, possibly using a local access mechnisim on the VoStore? service. A more complex case would be where a user invokes a different VoService and asks it to store the results in a specific VoStore? service, co-located or integrated with, the other VoService. In both cases, the user would only have access to their own x509 certificate (or a proxy version of it), and so the VoStore? or VoService calls would be authenticated using the user's certificate. The resulting files in the VoStore? service would be owned by the user's identity. With 'owner' = 'all permissions' access control on the VoStore?, this would mean that the user's VoSpace? service would not able to access the file using its own (VoSpace? service) identity.Releasing file from VoSpace?
There are several cases where a user may want direct access to a file in a VoStore?, using their own identity. The simplest case would be where a user instructs a VoSpace? service to transfer a file to a local VoStore? service, and then wants to access the file directly, using a separate GUI or command line tool, possibly via a local access mechanism on the VoStore? service. A more complex case would be where a user instructs VoSpace? to transfer a file to a specific VoStore? service, co-located or integrated with, another VoService. The user then wants the other VoService to access the file, using their identity rather than the VoSpace? services identity. In both cases, because the VoSpace? service initiated the transfer, the file in VoStore? would be owned by the VoSpace? service. This means that the VoStore? service would not allow the user to access the file directly using their own identity.Solutions
Direct change owner
One of the simplest solutions would be to allow one identity to assign the ownership of a file to a different identity. In the first use case, the user would import the file into the local VoStore?, and then assign the ownership to their corresponding VoSpace? service. Their VoSpace? service would then be able to access the file on their behalf. In the second use case, the user would instruct their VoSpace? service to transfer the file to the specified VoStore?, and then assign ownership to the user's identity. They would then be able access the file directly using their own identity. However, there is a security problem inherent in this model. Allowing one identity to assign ownership to another identity would allow users to hide, or deny knowledge of, incriminating or malicious content. User 'suspicious.user' places a malicious program into a VoStore? under their own identity, and then assigns ownership to 'innocent.user'. Any attempt to trace who is responsible for the malicious program will lead to 'innocent.user' and not to 'suspicious.user'. Although this type of use is unlikely at the moment, if we intend to build a reliable and secure system we should avoid designing a system with loopholes like this that may cause significamt security problems later on.Allow adoption
We could make the transfer of ownership require two steps, a grant by the 'current.owner', to allow 'new.owner' to adopt the file. Followed by a second call from 'new.owner' to accept the adoption, changing the ownership to their identity. This would prevent 'suspicious.user' from assigning ownership of 'malicious.content' to 'innocent.user' without 'innocent.user's consent. In the first use case, the user would import the file into the local VoStore?, and then grant their VoSpace? service permission to adopt the file. The user could then instruct their VoSpace? service to adopt the file, changing the ownership of the service's own identity, and adding the file to the user's VoSpace? tree. In the second use case, the user would instruct their VoSpace? service to transfer the file to the specified VoStore?, and then grant their own identity permission to adopt the file. When the file is transferred into the VoStore?, it would be owned by the VoSpace? service. As the file owner, the VoSpace? service would be able to [XXXXXX] the user's identity permission to adopt the file. The user would then be able to use local command line or GUI tools to adopt the file, changing the ownership to their own identity. This would then enable them to access the file directly, without going via their VoSpace? service. Using this technique, the same change in ownership occurs, but one identity is not able to change ownership of, and implied responsibility for, a file in a VoStore? without the recipient identity's knowledge.Use delegated certificates
Eventually, all of our services should be able to use delegated proxy certificates to act on behalf of a user using their own identity to authenticate SOAP calls. With this in place, the VoSpace? service would not need to use its own identity to access files in a VoStore?. Any action performed by a VoSpace? service should have been initiated by an authenticated user, and so the VoSpace? service would be able to use a delegated proxy certificate for the user's identity. This means that all the files in the VoStore? services could be owned by the user's identity, regardless of whether they were imported directly by the user or by using a VoSpace? service to import the file. However, this removes the ability of the VoSpace? service to control what happens to a file registered in VoSpace?. If files registered in VoSpace? are owned by the user's own identity, then there is nothing to prevent the user from deleting or modifying the file by accessing the VoStore? directly. This can cause a lot of additional problems and complexity in the design of the VoSpace? service, as it can no longer assume that a (VoSpace?) registered file placed in a VoStore? will not be modified by an external agent using the user's identity. This means that although it would be possible for the VoSpace? service to use a proxy certificate to access files owned by the user's identity, we would still want to enforce the separation of ownership. In order to maintain the VoSpace? service's control over registered files, all files in a VoStore? that have been registered in a VoSpace? service should be owned by the service, and not by the user identity.File adoption
This section outlines the main interactions that would need to occur to enable a user to import a file into a local VoStore? service, and then get their VoSpace? service to adopt the file.Step one - import
The client calls VoStore? service and initiates an import, authenticating the SOAP message using the users x509 certificate. The VoStore? service replies with the new file identifier, and a URL to send the data to.
Client VoStore VoSpace
|
| ImportInit
\------------------------------\
[Auth : x509 cn=user.. ] |
|
File
*[File : ivo://vostore/.. ]*
*[Owner : x509 cn=user.. ]*
|
/------------------------------/
| [File : ivo://vostore/.. ]
| [URL : http://vostore/..]
|
The client transfers the data into VoStore? service, using the URL supplied by the VoStore? service.
Note, if this is a DIME transfer, then the put call will also be authenticated by the user's
x509 certificate.
Client VoStore VoSpace
|
| PUT
\------------------------------\
[Auth : x509 cn=user.. ] |
[URL : http://vostore/..] |
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=user.. ]
*[Size : xxxx Mbytes ]*
The file is now in VoStore?, with the owner set to the user's x509 identity.
Step two - adopt init (VoStore?)
In order to enable the VoSpace? service to adopt the file, the client needs to notify the VoStore? service who to grant adoption rights to. The client calls the VoStore? service asking it to allow the VoSpace? service to adopt the file.
Client VoStore VoSpace
|
| AdoptInit
\------------------------------\
[Auth : x509 cn=user.. ] |
[Adopt : x509.cn=vospace.. ] |
[File : ivo://vostore/.. ] |
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=user.... ]
*[Adopt : x509 cn=vospace.. ]*
At this point, the file is still owned by the user, but the VoSpace?
service is now allowed to adopt the file and claim ownership.
This aviods the problem of having an orphaned file with no ownership during the adoption process.
If the client just released the file, by setting the owner to null without specifying the recipient,
then another identity could claim ownership of the file before the VoSpace? service was able to adopted it.
Alternatively, a user would be able to release a file by setting the ownership to null, and then not
tell the VoSpace? service to adopt the file. This would leave an orphaned file on the system with
no registered owner.
Step three - adopt file (VoSpace?)
The client calls the VoSpace? service and tells it to adopt a file in VoStore? service, giving it theivo://... identifier of the file to adopt.
Client VoStore VoSpace
|
| AdoptFile
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[File : ivo://vostore/... ] |
Node
*[Node : ivo://vospace/.. ]*
*[File : ivo://vostore/.. ]*
Step four - adopt file (VoStore?)
As part of the adoption process, the VoSpace? service calls the VoStore? service to request a change of ownership from the user's identity to the VoSpace? services own x509 identity.
Client VoStore VoSpace
|
| AdoptFile
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[File : ivo://vostore/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptFile |
/---------------------------------/
| *[Auth : x509.cn=vospace.. ]*
| [File : ivo://vostore/.. ]
|
File
[Ident : ivo://vostore/.. ]
*[Owner : x509 cn=vospace.. ]*
The file in VoStore? is now owned by the VoSpace? service, and apperas in the VoSpace?
node tree for the user's account.
Alternative sequence
Suggested by Once we have the ability to use proxy certificates, the VoSpace? service can act on behalf of the user, using a proxy certificate to authenticate using the user's own identity. In which case, the VoSpace? service can make both theadoptInit() and
the adoptFile method calls.
Step one - import
The client starts the sequence by importing the file into the VoStore? as before.
Client VoStore VoSpace
|
| ImportInit
\------------------------------\
[Auth : x509 cn=user.. ] |
|
File
*[File : ivo://vostore/.. ]*
*[Owner : x509 cn=user.. ]*
|
/------------------------------/
| [File : ivo://vostore/.. ]
| [URL : http://vostore/..]
|
|
| PUT
\------------------------------\
[Auth : x509 cn=user.. ] |
[URL : http://vostore/..] |
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=user.. ]
*[Size : xxxx Mbytes ]*
The file is now in VoStore?, with owner set to the user's x509 identity.
Step two - adopt file
The user no longer needs to calladoptInit() on the VoStore? service to initiate the adoption,
as the VoSpace? service can do this itself, using a proxy certificate to act on behalf of the user.
This means that the client can skip this step, and just call the VoSpace? service and tell
it to adopt the file in VoStore? service, giving it the ivo://... identifier of the file to adopt.
Client VoStore VoSpace
|
| AdoptFile
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[File : ivo://vostore/... ] |
Node
*[Node : ivo://vospace/.. ]*
*[File : ivo://vostore/.. ]*
Step three - adopt init
Using a delegated certificate, the VoSpace? service can call the VoStore? service using the user's identity to setup the adoption.
Client VoStore VoSpace
|
| AdoptFile
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[File : ivo://vostore/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| *[Auth : x509 cn=user.. ]*
| *[Adopt : x509.cn=vospace.. ]*
| [File : ivo://vostore/.. ]
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=user.... ]
*[Adopt : x509 cn=vospace.. ]*
Step four - adopt file
Having set up the adoption using the user's identity, the VoSpace? service can then call the VoStore? to confirm the adoption using its own identity.
Client VoStore VoSpace
|
| AdoptFile
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[File : ivo://vostore/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| [Auth : x509 cn=user.. ] |
| [File : ivo://vostore/.. ] |
| *[Adopt : x509.cn=vospace.. ]* |
| |
File |
[File : ivo://vostore/.. ] |
[Owner : x509 cn=user.... ] |
*[Adopt : x509 cn=vospace.. ]* |
|
AdoptFile |
/----------------------------------/
| *[Auth : x509.cn=vospace.. ]*
| [File : ivo://vostore/.. ]
|
File
[Ident : ivo://vostore/.. ]
*[Owner : x509 cn=vospace.. ]*
[Size : xxxx Mbytes ]
The file in VoStore? is now owned by the VoSpace? service, and appears in the VoSpace?
node tree for the user's account.
The same number of SOAP calls are involved, but both the adoptInit()
and the adoptFile() calls to the VoStore? are made by the VoSpace?
service and not by the client. This reduces the complexity from the client's view point,
placing the burden of setting up the adoption on the VoSpace? service.
File release
This section outlines the main interactions that would need to occur to enable a user to gain local access to a file imported into a VoStore? via a VoSpace? service. If we assume we already have the VoSpace? registered file in our local VoStore?, with the ownership set to the VoSpace? services identity. In order to access the file directly, the client needs to ask the VoSpace? to transfer ownership of the file to the user's identity.Step one - adopt init
The client starts the sequence by calling the VoSpace? service, asking to initiate an adoption.
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
In response, the VoSpace? service calls the VoStore? service, setting up the adoption transfer to the user's identity.
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| [Auth : x509 cn=vospace.. ]
| [File : ivo://vostore/.. ]
| *[Adopt : x509.cn=user.. ]*
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=vospace.. ]
*[Adopt : x509 cn=user.. ]*
At this point, we have three possible options for when to delete the corresponding node from the VoSpace? tree.
The simplest form is that the VoSpace? service deletes the node when the adoption is initiated,
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| [Auth : x509 cn=vospace.. ] |
| [File : ivo://vostore/.. ] |
| *[Adopt : x509.cn=user.. ]* |
| |
File |
[File : ivo://vostore/.. ] |
[Owner : x509 cn=vospace.. ] |
*[Adopt : x509 cn=user.. ]* |
Node
*[deleted]*
The file is now released from the VoSPace? services control at this point, and the client is free to
call the VoStore? service and adopt the file.
Step two - adopt file
The client can now call the VoStore? service to accept the adoption.
Client VoStore VoSpace
|
| AdoptFile
\------------------------------\
[Auth : x509 cn=user.. ] |
[File : iov://vostore/.. ] |
|
File
[File : ivo://vostore/.. ]
*[Owner : x509 cn=user.. ]*
However, this sequence does leave a gap, between the call from the VoSpace? service to initiate the adoption
and the call from the client to accept it, during which the file is nominally owned by the VoSpace? service, but
the corresponding node has been deleted from the VoSpace? services metadata tree.
Step three - adopt done (callback)
One solution to this would be to leave the VoSpace? node in place when the adoption is initiated, and register a callback to the VoSpace? service which is called by the VoStore? service when the adoption is accepted by the client.
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
| [Auth : x509.cn=user.... ] |
| [Node : ivo://vospace/... ] |
| Node
| [Node : ivo://vospace/.. ]
| [File : ivo://vostore/.. ]
| [Adopt : x509.cn=user.. ]
| |
| AdoptInit |
| /----------------------------------/
| | [Auth : x509 cn=vospace.. ]
| | [File : ivo://vostore/.. ]
| | *[Adopt : x509.cn=user.. ]*
| | *[Notify : ivo://vospace/.. ]*
| |
| File
| [File : ivo://vostore/.. ]
| [Owner : x509 cn=vospace.. ]
| *[Adopt : x509 cn=user.. ]*
| *[Notify : ivo://vospace/.. ]*
|
| AdoptFile
\------------------------------\
[Auth : x509 cn=user.. ] |
[File : iov://vostore/.. ] |
|
File
[File : ivo://vostore/.. ]
*[Owner : x509 cn=user.. ]*
|
| AdoptDone
\---------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
*[Adopt : x509.cn=user.. ]* |
|
Node
*[deleted]*
This avoids having a file in the VoStore? owned by the VoSpace? service, but with no corresponding
node in the VoSpace? metadata tree.
However, this does mean that the VoSpace? service relies on the VoStore? service to complete the sequence
by calling the callback to notify it when the adoption has been completed.
If the VoSpace? service is able to issue a delegated proxy certificate to act on the user's
behalf, then it is possible to use a much simpler sequence to achieve the same effect.
Step one - adopt init
As before, the sequence starts when the client calls the VoSpace? service to initiate the adoption, and the VoSpace? service calls the VoStore? service as the current owner of the file, to initiate the adoption at the VoStore? level.
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| [Auth : x509 cn=vospace.. ]
| [File : ivo://vostore/.. ]
| *[Adopt : x509.cn=user.. ]*
|
File
[File : ivo://vostore/.. ]
[Owner : x509 cn=vospace.. ]
*[Adopt : x509 cn=user.. ]*
Step two - adopt file
If the VoSpace? service is able to use a delegated proxy certificate to act on behalf of the user, then the VoSpace? service can call the VoStore? service using the user's identity to accept the adoption.
Client VoStore VoSpace
|
| AdoptInit
\----------------------------------------------------------------\
[Auth : x509.cn=user.... ] |
[Node : ivo://vospace/... ] |
Node
[Node : ivo://vospace/.. ]
[File : ivo://vostore/.. ]
|
AdoptInit |
/----------------------------------/
| [Auth : x509 cn=vospace.. ] |
| [File : ivo://vostore/.. ] |
| *[Adopt : x509.cn=user.. ]* |
| |
File |
[File : ivo://vostore/.. ] |
[Owner : x509 cn=vospace.. ] |
*[Adopt : x509 cn=user.. ]* |
|
AdoptFile |
/----------------------------------/
| *[Auth : x509 cn=user.. ]* |
| [File : ivo://vostore/.. ] |
| |
File |
[File : ivo://vostore/.. ] |
*[Owner : x509 cn=user.. ]* |
|
Node
*[deleted]*
Because the VoSpace? service does both of the adoption calls, adoptInit() using its own identity,
and adoptFile() using a proxy certificate for the user's identity, the VoSpace? service knows
that the adoption has been completed.
The VoSpace? service can then delete the corresponding node without having to worry about leaving an orphaned
file in VoStore? owned by the VoSpace? service without a corresponding node in the metadata tree. |
Click here for the AstroGrid Service Web |
This is the AstroGrid Development Wiki |
|
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback