Version 4 (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 indicating to the portal that it is !OAuth enabled.
  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 re