Changes between Version 4 and Version 5 of MashMyData/OAuth

Timestamp:

05/07/10 16:36:22 (10 years ago)

Author:

pjkersha

Comment:

--

MashMyData/OAuth

@@ -17 +17 @@
  1. The WPS request an !OAuth ''request'' token and
  1. returns this to the Portal Trust Registry for approval.
- 1. The WPS is already in the list of trusted delegates for this user and so
+ 1. The WPS is already in the list of trusted delegates for this user and so ...
  1. the request is marked as approved.
  1. The Portal can now send the !OAuth request token to the CEDA Token Service to request an !OAuth Access Token.
- 1. The Token Service checks the re
+ 1. The Token Service checks the request token is approved and issues an Access Token.
+ 1. The Portal re-issues its request to the WPS but this time with the Access Token.  The WPS accepts this request: the Portal is acting on behalf of the user.
+ 1. The WPS requires data from the CEDA TDS in order to execute its processing job.  It makes a request but gets an unauthorized response.
+ 1. Following the same procedure as before, the WPS like the portal geta delegated authority to act on behalf of the user.  Note that this time an alternate path is shown at the Portal Trust Registry.  The registry has no entry for the WPS for this user.  It makes a request to the user to get approval.  This is over some other protocol to HTTP: e-mail, SM or other.  This protocol has security implications so its nature is TBD.
+ 1. The end result of the delegation process for the WPS is that it gets an !OAuth Access Token which it can use to submit to the TDS.
+ 1. The TDS accepts this and allows the WPS to act on behalf of the user.
+ 1. The TDS returns the requested data to the WPS.
+ 1. The WPS executes its job and returns the response to the Portal
+ 1. The Portal in turn responds to the user.
 [[Image(source:TI12-security/trunk/NDGSecurity/documentation/MashMyData/OAuthWorkflow.png)]]