RCauth.eu and MasterPortal VOPortal integration guide

Overview

This page describes the steps for a VO portal or Science Gateway to obtain proxy certificates from the RCauth.eu online CA.

Note that VO portals do not directly contact the RCauth CA, but use an intermediate service, a so-called Master Portal, which handles most of the complexity. From the point of view of a VO portal, a Master Portal is an OpenID Connect Provider, with an integrated protected endpoint for obtaining proxy certificates.

Integration Workflow

Register a new client

Register a new client at a Master Portal at the /register endpoint:

• E.g. for the EGI development instance:
  https://masterportal-pilot.aai.egi.eu/mp-oa2-server/register
  
• or the EGI production instance:
  https://aai.egi.eu/mp-oa2-server/register

NOTE: Make sure to store the client_id and client_secret in a secure place.

Get the client approved

In order to get the client approved, send an email to ... to request client approval.

Implement an OIDC Connect flow to obtain a proxy chain

The steps needed to obtain a proxy certificate from the RCauth.eu CA via the Master Portal follow the standard OIDC Authorization Flow. The first few steps follow the generic OAuth for MyProxy protocol, the last step in the Master Portal specific OAuth for MyProxy GetProxy Endpoint:

1. VO portal initiates the flow by sending the user to the /authorize endpoint on the Master Portal. Parameters (see Client Requests Authorization):
   • client_id=...
   • response_type=code
   • redirect_uri=...
   • state=...
   • scope="openid edu.uiuc.ncsa.myproxy.getcert"
     
   The scope edu.uiuc.ncsa.myproxy.getcert is needed for obtaining proxy certificates.
   Optionally the VO portal can redirect the user to a specific IdP by also sending an idphint parameter. This is a RCauth / MasterPortal extension (see also Master Portal Internals#The_IdP_Hint).
   • idphint=... (fill in URL-encoded entityID of the IdP).
2. When the authorization flow succeeds, an authorization grant is sent as code parameter to the redirect_uri (see Authorization Response).
3. The VO portal uses the authorization grant to obtain an access_token, an id_token and optionally a refresh_token from the /token endpoint. Parameters (see Access Token Request):
   • client_id=...
   • client_secret=...
   • grant_type=authorization_code
   • code=... (fill in URL-encoded value of the code received)
   • redirect_uri=...
4. When successful, the response is a JSON including the access_token, id_token (and the refresh_token when configured). (see Access Token Response)
5. The VO portal can optionally access the /userinfo endpoint using the access_token. Note that it can get the same information also from the id_token. Parameters (see UserInfo Request):
   • access_token=...
6. The VO portal can now obtain a proxy certificate from the /getproxy endpoint using the access_token, and authenticating using its client_id and client_secret. Parameters (see OAuth for MyProxy GetProxy Endpoint):
   • client_id=...
   • client_secret=...
   • access_token=...
   Optionally, it can also requested a proxy lifetime, in seconds, to override the default set on the server (typically 12 hours):
   • proxylifetime=...
   and the name of a VO plus optionally vomses information (the latter is needed unless the VO is configured on the Master Portal):
   • voms=... (e.g. testvo or testvo:/testvo/Role=VO-Admin)
   • vomses=... (e.g. the URL-encoded value of '"testvo" "vomsserver.example.org" "15000" "/C=NL/O=Example/OU=Test/CN=vomsserver.example.org" "testvo"')