Difference between revisions of "OAuth for MyProxy GetProxy Endpoint"

From PDP/Grid Wiki
Jump to navigationJump to search
(protocol specification doneish)
 
(29 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[http://grid.ncsa.illinois.edu/myproxy/oauth/ OAuth for MyProxy] (OA4MP) is based around the [https://docs.google.com/document/d/1cs3peO9FxA81KN-1RC6Z-auEFIwRbJpZ-SFuKbQzS50 OIDC/OA4MP Protocol], which is a modified version of [http://openid.net/specs/openid-connect-core-1_0.html OpenID Connect]. The modifications introduced by OA4MP include the [https://docs.google.com/document/d/1cs3peO9FxA81KN-1RC6Z-auEFIwRbJpZ-SFuKbQzS50/pub#h.3khs91kr9igo GetCert Endpoint] which is used by the OA4MP Client (ex. Science Gateway) to retrieve an End Entity Certificate (EEC) on behalf of the authenticated user. In certain scenarios the use of EECs can be replaced by 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.   
+
[http://grid.ncsa.illinois.edu/myproxy/oauth/ OAuth for MyProxy] (OA4MP) implements the [http://goo.gl/VnMKXS OIDC/OA4MP Protocol], which is an extension of the [http://openid.net/specs/openid-connect-core-1_0.html OpenID Connect] specification. The modifications introduced by OA4MP on top of OIDC include the [http://goo.gl/VnMKXS#h.3khs91kr9igo 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 [https://tools.ietf.org/html/rfc3820 RFC3820] Proxy Certificates.<br>
 +
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.   
  
We propose adding a GetProxy Endpoint into the OIDC/OA4MP Protocol, which returns Proxy Certificates. The main differences between the GetProxy and GetCert Endpoint are:
+
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:
  
* returns Proxy Certificates
+
* return RFC3820 Proxy Certificate chain
* generates CSR on server side instead of client side
+
* generates keypair and CSR on server side instead of client side
 
* accepts VONAME and VOMSES parameters  
 
* accepts VONAME and VOMSES parameters  
 +
 +
For the ''technical implementation details'' of the Getproxy Endpoint, see [[OAuth_for_MyProxy_GetProxy_Endpoint_-_Implementation | here]].
  
 
== Protocol Specification ==
 
== 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:
+
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:
  
 
{| class="wikitable" style="width: 55%;"
 
{| class="wikitable" style="width: 55%;"
Line 19: Line 22:
 
|-
 
|-
 
| style="width: 25%;" | client_id
 
| style="width: 25%;" | client_id
| style="width: 33%;" |REQUIRED if not provided in <br />HTTP Basic Authorization header
+
| style="width: 33%;" |REQUIRED
 
| The client identifier issued at registration time.
 
| The client identifier issued at registration time.
  
 
|-
 
|-
 
| style="width: 25%;" |client_secret
 
| style="width: 25%;" |client_secret
| style="width: 33%;" |REQUIRED if not provided in <br />HTTP Basic Authorization header
+
| style="width: 33%;" |REQUIRED
 
| The client secret issued at registration time.
 
| The client secret issued at registration time.
  
Line 40: Line 43:
 
| style="width: 25%;" |voname
 
| style="width: 25%;" |voname
 
| style="width: 33%;" |OPTIONAL
 
| style="width: 33%;" |OPTIONAL
| Specifies one or more VO to connect to for membership information. The VO name can be followed by additional group and role request. (see 'man voms-proxy-init' under -voms)
+
| 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'').
  
 
|-
 
|-
 
| style="width: 25%;" |vomses
 
| style="width: 25%;" |vomses
 
| style="width: 33%;" |OPTIONAL
 
| style="width: 33%;" |OPTIONAL
| Specifies VOMS server information under 'vomses' file format
+
| Specifies VOMS server information in 'vomses' file format.
  
 
|}
 
|}
  
Just like in case of GetCert, the access_token, client_id and client_secret parameters are there to ensure the authenticity of the request. Note that the 'certreq' parameter, containing the Certificate Signing Request (CSR), is no longer sent along in the request. 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 off the OA4MP Client, thus making it more lighweight and easily adaptable by different communities.
+
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 they are to the subsequent [http://grid.ncsa.illinois.edu/myproxy/protocol/ MyProxy GET] request.
+
Requesting a VOMS Proxy Certificate can be done by using the 'voname' and 'vomses' request parameters. These parameters are passed as-is to the [http://grid.ncsa.illinois.edu/myproxy/protocol/ MyProxy GET] request executed by the MasterPortal.
  
'''Note:''' The VOMSES string is useful in scenarios where the user would like to get membership information from a VOMS server which is not configured in the backend MyProxy Server 'vomses' file.
+
'''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 ===
 
=== Example Request ===
Line 59: Line 62:
 
POST Example
 
POST Example
  
  POST /getcert HTTP/1.1
+
  POST /getproxy HTTP/1.1
  Host: myproxy.example.edu
+
  Host: masterportal.example.edu
 
  Content-Type: application/x-www-form-urlencoded
 
  Content-Type: application/x-www-form-urlencoded
 
   
 
   
Line 66: Line 69:
 
  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
 
  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/ -H "Host: myproxy.example.edu" -H "Content-Type: application/x-www-form-urlencoded" -X POST -d \
+
  curl --capath /etc/grid-security/certificates/ -d \
 
       'client_id=s6BhdRkqt3&client_secret=some_secret12345&access_token=8xLOxBtZp8&proxylifetime=43200&
 
       '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"' \  
+
       voname=superscience&vomses="testvo" "voms.example.edu" "15000" "/C=XX/O=Example/CN=myproxy.example.edu" "testvo"' \
      https://myproxy.example.edu/oauth2/getproxy
+
      https://masterportal.example.edu/oauth2/getproxy
  
 
=== Example Response ===
 
=== Example Response ===
Line 81: Line 84:
 
  MIIJ+DCCCOCgAwIBAgIEWVmVpjANBgkqhkiG9w0BAQsFADBVMQ0wCwYDVQQKEwRHcmlkMRMwEQYD
 
  MIIJ+DCCCOCgAwIBAgIEWVmVpjANBgkqhkiG9w0BAQsFADBVMQ0wCwYDVQQKEwRHcmlkMRMwEQYD
 
  VQQLEwpHbG9idXNUZXN0MRwwGgYDVQQDFhNkdW1teUBteS1kb21haW4uY29tMREwDwYDVQQDEwg3
 
  VQQLEwpHbG9idXNUZXN0MRwwGgYDVQQDFhNkdW1teUBteS1kb21haW4uY29tMREwDwYDVQQDEwg3
 +
 
  ...
 
  ...
 +
 
  BvjdU/+9xSlBnFm7v2thFcqienTP6cY/iCQPDzT9wv/fdv/DToy9oN0BrtYievZjZOLcjsczMD5M
 
  BvjdU/+9xSlBnFm7v2thFcqienTP6cY/iCQPDzT9wv/fdv/DToy9oN0BrtYievZjZOLcjsczMD5M
 
  KXOr/StOe+qDtT6CXwpzGNE4QJYTl8yoQguZaSsGxgP2PDPS0G0dLGTv8YvG3Fle
 
  KXOr/StOe+qDtT6CXwpzGNE4QJYTl8yoQguZaSsGxgP2PDPS0G0dLGTv8YvG3Fle
Line 88: Line 93:
 
  MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCAIZ9nkUddKLznkHuda9yRxPP5
 
  MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCAIZ9nkUddKLznkHuda9yRxPP5
 
  j2JO9U0CFmr4EmKjvza8BstyndksT235zODXIs3wVVYqxxMqH4J9181MlCxs8f7GXRlgDlY3oSa/
 
  j2JO9U0CFmr4EmKjvza8BstyndksT235zODXIs3wVVYqxxMqH4J9181MlCxs8f7GXRlgDlY3oSa/
 +
 
  ...
 
  ...
 +
 
  eM7xUIqehh+Yy01oKEcSNE3ykvySXxp7JBvREhNCaObxpMhi0JAMaAJ0atf9e8E/DFOccy6P9McZ
 
  eM7xUIqehh+Yy01oKEcSNE3ykvySXxp7JBvREhNCaObxpMhi0JAMaAJ0atf9e8E/DFOccy6P9McZ
 
  ysKQufEOgePsck/OrFEDmGqs+bA=
 
  ysKQufEOgePsck/OrFEDmGqs+bA=
Line 95: Line 102:
 
  MIIDQjCCAiygAwIBAgIEBE72YDALBgkqhkiG9w0BAQswQjENMAsGA1UEChMER3JpZDETMBEGA1UE
 
  MIIDQjCCAiygAwIBAgIEBE72YDALBgkqhkiG9w0BAQswQjENMAsGA1UEChMER3JpZDETMBEGA1UE
 
  CxMKR2xvYnVzVGVzdDEcMBoGA1UEAxYTZHVtbXlAbXktZG9tYWluLmNvbTAeFw0xNjAxMDYxNTAx
 
  CxMKR2xvYnVzVGVzdDEcMBoGA1UEAxYTZHVtbXlAbXktZG9tYWluLmNvbTAeFw0xNjAxMDYxNTAx
 +
 
  ...
 
  ...
 +
 
  XZxr1zbbcPnol8vETpTiRvW3I8ms3PBwgWXE4xIbN8Myng7UgPjasv+JOykx+3UIVD1FblZAXdnH
 
  XZxr1zbbcPnol8vETpTiRvW3I8ms3PBwgWXE4xIbN8Myng7UgPjasv+JOykx+3UIVD1FblZAXdnH
 
  fBJa7cu/xGomko+7i0opoQewaRcPLmGbL6xVuW3MERwIPfiKqsz+4w==
 
  fBJa7cu/xGomko+7i0opoQewaRcPLmGbL6xVuW3MERwIPfiKqsz+4w==
Line 102: Line 111:
 
  MIICnjCCAgegAwIBAgICAMEwDQYJKoZIhvcNAQELBQAwTzENMAsGA1UEChMER3JpZDETMBEGA1UE
 
  MIICnjCCAgegAwIBAgICAMEwDQYJKoZIhvcNAQELBQAwTzENMAsGA1UEChMER3JpZDETMBEGA1UE
 
  CxMKR2xvYnVzVGVzdDEpMCcGA1UEAxMgR2xvYnVzIFNpbXBsZSBDQSBmb3IgRGVtbyBQb3J0YWww
 
  CxMKR2xvYnVzVGVzdDEpMCcGA1UEAxMgR2xvYnVzIFNpbXBsZSBDQSBmb3IgRGVtbyBQb3J0YWww
 +
 
  ...
 
  ...
 +
 
  IACngeT/1vXoC/2s03B9dwK4s/pBs7EVG/9kf5Wlew3IVwtcqTI2kDXUPiLey+ro37Qct5htseft
 
  IACngeT/1vXoC/2s03B9dwK4s/pBs7EVG/9kf5Wlew3IVwtcqTI2kDXUPiLey+ro37Qct5htseft
 
  E2TwLFzbCOo9wI/6cCu7uSOyxGwVlk+rvTfJFsaAmYOMeQuytQCTRy9loFNz6Hk=
 
  E2TwLFzbCOo9wI/6cCu7uSOyxGwVlk+rvTfJFsaAmYOMeQuytQCTRy9loFNz6Hk=
 
  -----END CERTIFICATE-----
 
  -----END CERTIFICATE-----
 +
 +
=== Example client code ===
 +
 +
For example code, see this [https://rcdemo.nikhef.nl/demobasic/ simple PHP demonstrator], which shows how the <tt>/getproxy</tt> endpoint can be used to obtain a valid proxy certificate.

Latest revision as of 10:11, 5 September 2019