Changes between Version 5 and Version 6 of MashMyData/MyProxy

Timestamp:

12/07/10 14:10:53 (11 years ago)

Author:

pjkersha

Comment:

--

MashMyData/MyProxy

@@ -2 +2 @@
 [[PageOutline]]
 == Sequence ==
+=== Prerequisites ===
+The user has an OpenID but is not registered with an account in the ESG federation.
+
 === Actors ===
  1. User
- 1. User's browser
+ 1. ESG !MyProxy Server - some !MyProxy server in the ESG federation for which the user can register with an account and then obtain credentials from
  1. !MashMyData web portal application
- 1. Portal Trust Registry: a registry containing a list of trusted services one per user.  These are services which the user has previously agreed to delegate to act on their behalf.  Trust settings could be set with an expiry.  For the purposes of this project, this service could be co-located with the portal.  For production use it would be likley to be associated with the user's IdP (Identity Provider)
+ 1. 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
  1. 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. CEDA TDS
- 1. CEDA Token Service: issues OAuth request and access tokens for the WPS and TDS.  There is at least one Token Service per OAuth realm.  IT could be implemented as a filter in front of both the WPS and TDS.
 
 === Process ===
  1. The user signs in at the portal using OpenID (deliberately shown compressed into a single step for simplicity).
+ 1. 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.
+ 1. The user makes a request which initiates a WPS job.
+ 1. 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.  
+ 1. The Portal makes a call to the WPS but receives an authentication challenge response.
+ 1. It retries this time passing the credentials it's cached from call to the ESG !MyProxy Server - see step 2.
+ 1. The WPS accepts the user credentials passed in the Portal request and initiates the job.  This job entails calling a TDS at CEDA.
+ 1. The WPS gets an authentication challenge response so it calls the CEDA !MyProxy server to obtain a credential
+ 1. The CEDA !MyProxy server grants the request since a credential was uploaded previously (step 4) and this credential may be delegated to the WPS.
+ 1. The WPS retries its call to the TDS using the proxy certificate obtained.
+ 1. The TDS accepts the proxy credential and returns the requested data.
+ 1. The WPS completes its job and returns a response to the Portal.
+ 1. The Portal sends a response to the user's browser.
 
 [[Image(source:TI12-security/trunk/NDGSecurity/documentation/MashMyData/MyProxyWorkflow.png)]]