OAuth for MyProxy GetProxy Endpoint
OAuth for MyProxy (OA4MP) implements the OIDC/OA4MP Protocol, which is an extension of the OpenID Connect specification. The modifications introduced by OA4MP on top of OIDC include the GetCert Endpoint which is used by the OA4MP Client (e.g. a Science Gateway) to retrieve an End Entity Certificate (EEC) on behalf of the authenticated user. Typical workflows on the other hand usually do not directly make use of EECs, but instead use RFC3820 Proxy Certificates.
Proxy Certificates, usually having a shorter lifetime than EECs, are less likely to be used maliciously given their short validity period, while still conveying the same authentication information as an EEC would. Moreover, a Proxy Certificate can contain additional authorization information in the form of VOMS Extensions.
The AARC-developed MasterPortal therefore adds a GetProxy Endpoint to the OIDC/OA4MP Protocol, which directly returns Proxy certificate chains to its clients. The main differences between the GetProxy and GetCert Endpoint are:
- return RFC3820 Proxy Certificate chain
- generates keypair and CSR on server side instead of client side
- accepts VONAME and VOMSES parameters
For the technical implementation details of the Getproxy Endpoint, see here.
Protocol Specification
The GetProxy Endpoint, just like the GetCert Endpoint, is an OAuth2.0 protected resource that returns a proxy certificate. This proxy certificate consists of a certificate chain and private key of the proxy. The request made to the GetProxy Endpoint is made up of the following parameters:
| Name | Required | Description |
| client_id | REQUIRED | The client identifier issued at registration time. |
| client_secret | REQUIRED | The client secret issued at registration time. |
| access_token | REQUIRED | OIDC (OAuth 2.0) access token obtained with token request. Provided in 'Authorization: Bearer' header or as form value. |
| proxylifetime | OPTIONAL | Requested proxy lifetime (in seconds). In case this value exceeds the server side default, the request parameter is ignored. |
| voname | OPTIONAL | Specifies one or more VOs to connect to for membership information. The VO name can be followed by additional groups and roles. (Same format as for the -voms option to voms-proxy-init, see man voms-proxy-init). |
| vomses | OPTIONAL | Specifies VOMS server information in 'vomses' file format. |
Just as for the GetCert endpoint, the access_token, client_id and client_secret parameters are there to ensure the authenticity of the request. Note that the 'certreq' parameter (of the getcert request), containing the Certificate Signing Request (CSR), is not required. Instead, a new keypair and CSR are created on the server side and used in the subsequent MyProxy GET request. The motivation behind this change is to take the burden of key generation away from the OA4MP Client, thus making it more lightweight and easier to adopt by different communities.
Requesting a VOMS Proxy Certificate can be done by using the 'voname' and 'vomses' request parameters. These parameters are passed as-is to the MyProxy GET request executed by the MasterPortal.
Note: The VOMSES string is useful in scenarios where the client would like to make use of a VOMS server which is not configured locally in the back-end MyProxy Server (in its 'vomses' file, see 'man myproxy-server.config' under 'voms_userconf').
Example Request
POST Example
POST /getproxy HTTP/1.1 Host: masterportal.example.edu Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3&client_secret=some_secret12345&access_token=8xLOxBtZp8&proxylifetime=43200& voname=superscience&vomses=%22testvo%22%20%22voms.example.edu%22%20%2215000%22%20%22%2FC%3DXX%2FO%3DExample%2FCN%3Dmyproxy.example.edu%22%20%22testvo%22
curl --capath /etc/grid-security/certificates/ -d \
'client_id=s6BhdRkqt3&client_secret=some_secret12345&access_token=8xLOxBtZp8&proxylifetime=43200&
voname=superscience&vomses="testvo" "voms.example.edu" "15000" "/C=XX/O=Example/CN=myproxy.example.edu" "testvo"' \
https://masterportal.example.edu/oauth2/getproxy
Example Response
In case of a successful request the body of the response message contains the Proxy Certificate in PEM format. The first certificate in the chain is the proxy followed by its private key, and the rest of the chain.
HTTP/1.1 200 OK Content-Type: text/plain -----BEGIN CERTIFICATE----- MIIJ+DCCCOCgAwIBAgIEWVmVpjANBgkqhkiG9w0BAQsFADBVMQ0wCwYDVQQKEwRHcmlkMRMwEQYD VQQLEwpHbG9idXNUZXN0MRwwGgYDVQQDFhNkdW1teUBteS1kb21haW4uY29tMREwDwYDVQQDEwg3 ... BvjdU/+9xSlBnFm7v2thFcqienTP6cY/iCQPDzT9wv/fdv/DToy9oN0BrtYievZjZOLcjsczMD5M KXOr/StOe+qDtT6CXwpzGNE4QJYTl8yoQguZaSsGxgP2PDPS0G0dLGTv8YvG3Fle -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCAIZ9nkUddKLznkHuda9yRxPP5 j2JO9U0CFmr4EmKjvza8BstyndksT235zODXIs3wVVYqxxMqH4J9181MlCxs8f7GXRlgDlY3oSa/ ... eM7xUIqehh+Yy01oKEcSNE3ykvySXxp7JBvREhNCaObxpMhi0JAMaAJ0atf9e8E/DFOccy6P9McZ ysKQufEOgePsck/OrFEDmGqs+bA= -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDQjCCAiygAwIBAgIEBE72YDALBgkqhkiG9w0BAQswQjENMAsGA1UEChMER3JpZDETMBEGA1UE CxMKR2xvYnVzVGVzdDEcMBoGA1UEAxYTZHVtbXlAbXktZG9tYWluLmNvbTAeFw0xNjAxMDYxNTAx ... XZxr1zbbcPnol8vETpTiRvW3I8ms3PBwgWXE4xIbN8Myng7UgPjasv+JOykx+3UIVD1FblZAXdnH fBJa7cu/xGomko+7i0opoQewaRcPLmGbL6xVuW3MERwIPfiKqsz+4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIICnjCCAgegAwIBAgICAMEwDQYJKoZIhvcNAQELBQAwTzENMAsGA1UEChMER3JpZDETMBEGA1UE CxMKR2xvYnVzVGVzdDEpMCcGA1UEAxMgR2xvYnVzIFNpbXBsZSBDQSBmb3IgRGVtbyBQb3J0YWww ... IACngeT/1vXoC/2s03B9dwK4s/pBs7EVG/9kf5Wlew3IVwtcqTI2kDXUPiLey+ro37Qct5htseft E2TwLFzbCOo9wI/6cCu7uSOyxGwVlk+rvTfJFsaAmYOMeQuytQCTRy9loFNz6Hk= -----END CERTIFICATE-----
Example client code
For example code, see this simple PHP demonstrator, which shows how the /getproxy endpoint can be used to obtain a valid proxy certificate.
