Version 6 (modified by pjkersha, 11 years ago) (diff)


MashMyData Delegation with MyProxy



The user has an OpenID but is not registered with an account in the ESG federation.


  1. User
  2. ESG MyProxy Server - some MyProxy server in the ESG federation for which the user can register with an account and then obtain credentials from
  3. MashMyData web portal application
  4. CEDA MyProxy Server - a CEDA MyProxy server which is used to hold user proxy credentials for various services within CEDA to access when they are delegated tasks on the user's behalf
  5. CEDA WPS (OGC Web Processing Service): this will execute a job for the portal on behalf of the user. The job involves pulling data from another service, a TDS (THREDDS Data Server) also hosted at CEDA. Both services have access control in place.


  1. The user signs in at the portal using OpenID (deliberately shown compressed into a single step for simplicity).
  2. The Portal links the OpenID account to an ESG MyProxy server from which to obtain credentials. This is to allow for the fact that the user is not registered with ESG: they have an OpenID but no means of obtaining an SSL certificate required by some of the services for authentication. More details are needed: if the user is not registered with ESG, what is the link between the MyProxy account and the external OpenID account? Does the user need to authenticate twice: once with OpenID and once to obtain the MyProxy credentials? An initial registration stage is implied to register the user so that they can get a short term certificate from an ESG MyProxy server.
  3. The user makes a request which initiates a WPS job.
  4. The Portal anticipates that the WPS and possibly other services at CEDA will require delegated credentials so it performs a myproxy-init to upload a new proxy certificate to the CEDA MyProxy server specifying that the WPS and any other data access service at CEDA has permissions to obtain delegated credentials from it.
  5. The Portal makes a call to the WPS but receives an authentication challenge response.
  6. It retries this time passing the credentials it's cached from call to the ESG MyProxy Server - see step 2.
  7. The WPS accepts the user credentials passed in the Portal request and initiates the job. This job entails calling a TDS at CEDA.
  8. The WPS gets an authentication challenge response so it calls the CEDA MyProxy server to obtain a credential
  9. The CEDA MyProxy server grants the request since a credential was uploaded previously (step 4) and this credential may be delegated to the WPS.
  10. The WPS retries its call to the TDS using the proxy certificate obtained.
  11. The TDS accepts the proxy credential and returns the requested data.
  12. The WPS completes its job and returns a response to the Portal.
  13. The Portal sends a response to the user's browser.



This illustrates how delegation can work with proxy certificates and two MyProxy servers. One MyProxy server is used to obtain credentials. The second is used to upload delegated credentials which another delegate service can use:

  1. Obtain a user credential from a MyProxy server
  2. Upload it to another MyProxy server delegating permission for a given service to access it
  3. Service access a delegated credential
  1. User gets credential by calling a MyProxy service at their home site:
    $ myproxy-logon -s -o creds.pem
  2. They or some portal or middleware upload it to another MyProxy server so that a service, CEDA's WPS can obtain a delegated credential from it:
    $ myproxy-init -s -x -Z "/C=UK/O=CEDA/OU=MashMyData/CN=host/" -d -n
    A proxy certificate has been uploaded to which only the CEDA WPS is allowed to delegate from.
  3. The CEDA WPS, obtains a delegated credential so that it can run a job on the user's behalf:
    $ myproxy-logon -s -l "/O=MyIdP/CN=myusername" -n
    A credential has been received for user /O=MyIdP/CN=myusername in /tmp/x509up_u0.

Steps 1 and 2 could be performed by the Portal on behalf of the user.