[workspace-user] Delegating credentials with the 'workspace' command

[Tim Freeman]

On Mon, 16 Apr 2007 16:11:41 -0700
Duncan Penfold-Brown <dpb at uvic.ca> wrote:

> Hello Everyone -
> 
> I have a question about specifying delegated credential information in 
> my 'workspace' call to create workspaces. I have workspace-services 
> running on a cluster head node, and workspace-control running on an 
> attached worker node. I am able to create workspaces with images hosted 
> locally on the worker node (not using propagation) and with off-site 
> images (using gsiftp propagation). However, to create workspaces using 
> gsiftp propagation, I have to obtain valid credentials on both the 
> workspace-services head node and the workspace-control worker node.

The credentials for image node --> worker node transfers (propagation) should
be passwordless (proxy certificates generated every day via cron is an option).
Propagation is part of the "control plane", remote client credentials (that
would be delegated) should not come into play here.

Once the client get its files to the site, the "managed solution" takes over.

Delegation functionality in the workspace client is used for delegating staging
credentials to the GT container, e.g. for use with the RFT service that will
manage a 3rd party GridFTP transfer of files.  This is where client credentials
matter, in getting the files to the site, in what we're calling 'staging' as
opposed to 'propagation'.

It should be set up equivalently to the SCP situation, the privileged account
on the workspace-control node has the privileges to 1) retrieve files from the
image node and 2) start workspaces via sudo.  This account should never run any
code under the delegated credential of a remote client.

I apologize for the lack of clarity in the admin guide, this is something we
are actively addressing at the moment!


>  This 
> system uses proxy-based credentials, so in effect, this means that I 
> have to obtain a valid proxy on both the worker node and the head node 
> to be able to use gsiftp propagation. Currently, I am simply SSHing to 
> the head node and the worker node and obtaining credentials separately. 
> What I would like to be able to do is to obtain a credential on the 
> machine that I am executing the 'workspace' command on (in this case, 
> the services head node), and propagate that credential to the worker 
> node so that I don't have to obtain a credential for both machines; the 
> goal is to have a credential obtained on the head node be effective on 
> the  worker node that executes the gsiftp propagation call (as valid 
> credentials are needed to use gsiftp).
> 
> Currently, I am looking at the delegation parameters of the 'workspace' 
> command, but I'm not having an easy time figuring out what combination / 
> configuration I should use to accomplish the desired credential 
> propagation.

Sorry you're running into this:  it's not possible (it is possible of course,
but it would take coding -- however, it's not part of the model so it is not a
current pending development task). 

Thanks,
Tim


>  So far, I have tested the following command:
> 
> workspace --file 
> /usr/local/globus-4/share/workspace_client/tests/tty-test01-prop.epr 
> --metadata 
> /usr/local/globus-4/share/workspace_client/tests/workspace-metadata-tty1-propagation.xml 
> --request 
> /usr/local/globus-4/share/workspace_client/tests/deployment-request.xml 
> --delegation full --delegate 
> https://nnn.nnn.nnn.nnn:8443/DelegationService --delegateXf 
> --securityMech conv --authorization host  --serverCertificate 
> /etc/grid-security/hostcert.pem 
> -shttps://machine.location:8443/wsrf/services/WorkspaceFactoryService
> 
> 
> --delegation full      seems correct to me, though I'm not sure what the 
> 'limited' option would produce.
> --delegate               simply reflects the location of the 
> DelegationService
> --delegateXf           forces the credentials created to be used for 
> transfer (I think I should use this, as I need the credential for image 
> propagation, not file staging)
> --securityMech conv     this option is required for the delegation 
> option to facilitate gsi conversation
> --authorization       this field is confusing to me: I have tried using 
> 'self', 'host', 'none', and my certificate tag, and all have given 
> different errors.
> 
> I have also tried the command with an added '--serverCertificate [...]' 
> specifying the location of the hostcert.pem file on the head node. If 
> anyone has suggestions on how to make this system work, please let me 
> know. Any further explanation of the workspace command and the 
> credential parameters would also be greatly appreciated. If more 
> information is needed (eg: what error messages I am getting when I run 
> the above commands), again, just let me know.
> 
> Thanks,
> 
> Duncan Penfold-Brown
> University of Victoria, CA
> 
> 
>