ESGF Delegation

This page outlines possible solutions for supporting user delegation for ESGF.


Use cases like those explored for the MashMyData project have highlighted the need to support user delegation within the ESGF infrastructure. For MashMyData, a portal accesses a secured OGC Web Processing Service (WPS) and requests that executes a processing job which itself needs access to secured data served over OPeNDAP. The portal and WPS each require delegated credentials

OAuth Protected SLCS

The  CILogon project has shown how OAuth can be used to delegate to trusted clients to retrieve user credentials (an EEC) from a short-lived credential service (SLCS). This avoids the need for proxy certificates and so simplifies the configuration of services consuming credentials since no specialist SSL engine to correctly verify proxy certificate trust chains.

At CEDA, a Python-based implementation of OAuth 2.0 has been written ndg_oauth2. OAuth 2.0 has been selected over OAuth 1.0 to take advantage of the simplification in flows and messaging requirements. This has been used in a similar way to CILogon for a SLCS for  Contrail, a federated Cloud infrastructure project funded by the EU FP7 programme. It has also been used for the climate science e-infrastructure project  ExArch.

Issues for ESGF

  1. Use current CILogon OAuth 1.0 flow or move to OAuth 2.0
  2. If different, agree exact flow
  3. How to integrate with existing ESGF:
    • where does OAuth Server sit?
    • is it stateful so as to remember delegatee approvals?
    • role for 2-legged OAuth?
  4. How to manage sign in plus delegation in single step - OAuth/OpenID hybrid
  5. How to provide provenance information

OAuth 2.0 Protected SLCS Flow

This section outlines some of the work done to date with an OAuth 2.0 based SLCS:

Solution 1

The MyProxy server is the OAuth Resource server. Authorisation server and Reosurce server could sit in the same stack and possibly share state information. The Authorisation server can authenticate the client with SSL-based client authentication.


Solution 2

Alternative flow, simplifies the process by making the returned access token the EEC:



Solution 2 does simplify the flow, but 1) keeps the OAuth and SLCS semantics independent. Also, for 2) the access token will be public information when the client uses it in an SSL handshake with another peer. There may be advantages to keeping the access token as a shared secret for use amongst a set of trusted delegatees e.g. The WPS brokers an access token with an associated OAuth scope so that it a number of trusted parties (e.g. job brokers, processing chain members) can use the token to get delegated credentials themselves.

Options for Integration with ESGF

OAuth Server configuration

The OAuth Server could be associated with each ESGF Service Provider. However, if we wish it to be able to keep a list of trusted clients approved by users then this information will only have scope within the domain of the given SP. If the user visits another SP, potentially another OAuth Server will be used. All the users previous approval decisions will not be known to it. This would be confusing and frustrating for users.

An alternative is to associate the OAuth Server with the users IdP. In this way all user approval information would be hosted in one place at their home institution. This would enable the user to manage settings centrally through a single user workspace interface.

However, this approach would involve an OAuth Server discovery stage: a given Service Provider would need to know which OAuth Server to invoke for any given user. This is similar though to the OpenID sign in scenario. We could further exploit Yadis and add an entry in the XRDS document for the OpenID endpoint listing the OAuth Server address (see the entry for the third service below):

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
        <Service priority="1">
        <Service priority="20">
        <Service priority="30">
        <Service priority="0">

The user would simply enter their OpenID as before, or preferably just click on an icon or list item to select their IdP.

2-legged OAuth

Can this negate the need for user approval or is this policy too permissive?

Can  Client Credentials Grant be usefully exploited?

Sign in + Delegation in one step

In some scenarios, it may be necessary for the user to sign in at a given portal but in addition to give the portal the right to obtain a delegated credential on their behalf. An example is the WPS. The WPS may apply access control restrictions on the execution of jobs in which case the user needs to authenticate with the WPS. Those jobs themselves need delegated credentials so that they can make onward requests to protected resources. This implies the OAuth flow.

The  OpenID OAuth Extension appears to describe such a scenario. However, it seems to have been written for OAuth 1.0 and would need to be reviewed in the light of the OAuth 2.0 flow. Also, how widely is this pattern used - are there concerns about a custom solution that does not have widespread adoption?

Since in the example the portal receives an EEC representing the user from their IdP does this count as an assertion that the user authenticated with the IdP? If this is the case, haven't they effectively signed in with the Portal? If so, no OpenID / OAuth hybrid is required, a pure OAuth-based flow is sufficient.

Provenance of Credentials with OAuth Protected SLCS

With proxy certificates, a cert chain back to the issuing EEC provides information about the delegation steps. This is not the case with the OAuth protected SLCS since a fresh EEC is created. The extensions section of the issued EEC could contain information about the delegation steps e.g. a SAML authentication statement asserting that the OAuth client authenticated with the OAuth server.