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


MashMyData Delegation with OAuth



  1. User
  2. User's browser
  3. MashMyData web portal application
  4. 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)
  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.
  7. 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.


  1. The user signs in at the portal using OpenID (deliberately shown compressed into a single step for simplicity).
  2. The user initiates a request which triggers the Portal to call the CEDA WPS to execute a job on its behalf.
  3. The WPS returns an unauthorized response but it indicates to the portal that it accepts OAuth based delegation.
  4. The WPS request an OAuth request token and ...
  5. returns this to the Portal Trust Registry for approval.
  6. The WPS is already in the list of trusted delegates for this user and so ...
  7. the request is marked as approved.
  8. The Portal can now send the OAuth request token to the CEDA Token Service to request an OAuth Access Token.
  9. The Token Service checks the request token is approved and issues an Access Token.
  10. 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.
  11. The WPS requires data from the CEDA TDS in order to execute its processing job. It makes a request but gets an unauthorized response.
  12. Following the same procedure, the WPS in the same way as the portal did earlier, gets 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, SMS or other. This protocol has security implications so its nature is TBD.
  13. 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.
  14. The TDS accepts this and allows the WPS to act on behalf of the user.
  15. The TDS returns the requested data to the WPS.
  16. The WPS executes its job and returns the response to the Portal
  17. The Portal in turn responds to the user.