RCauth.eu and MasterPortal overview

From PDP/Grid Wiki
Revision as of 10:49, 3 September 2019 by Msalle@nikhef.nl (talk | contribs) (Msalle@nikhef.nl moved page AARC Pilot - RCAuth.eu to RCAuth.eu and MasterPortal overview: No longer pilot but production)
Jump to navigationJump to search

RCauth.eu

RCauth.eu is a white-label Research and Collaboration Authentication CA Service for Europe. For more detailed information about it including policies please refer to RCauth.eu website.

Background resources:

Self-Registration

In order to register a Master Portal to RCauth.eu, you can point your browser to the self-registration page. After you authenticate, you can fill in your Master Portal details and receive a generated client ID and secret via the browser which you can use in your Master Portal configuration.

Note: the new client still needs to be approved by an RCauth operator before actual use.

Architecture

RCAuth Prototype.svg

Components

  • Blue component [many] represent the Service Provider Portal which the user wants to use. These are usually the Science Gateways. We are expecting to see many such portals.
    • Example Portal : As an example, we provide several demo portals (written in php). These are a good starting point to learn how to interface with the Master Portal, in particular the Basic demo.
  • Red components [few] correspond to the Master Portal. We are expecting to see a few of these services.
    • Master Portal : acts as a caching service for user credential (proxy certificates), taking some load of the RCauth.eu backend. Moreover, it also intermediates between two separate trust domains: the domain (single) of the Delegation Server and the domains (many) of connecting Service Provider Portals (Science Gateways). This improves the scalability of the model, since instead of registering ALL Portals to the single Delegation Server directly, now registered Portals can be split between a few Master Portals running in front of the Delegation Server.
    • Credential Store : is a MyProxy server used by the Master Portal to actually store the user proxies.
  • Yellow components [one] represent an Online CA with a web frontend, and its what we call RCauth.eu. We are expecting to see only one of this component.
    • Delegation Server : is the web frontend service which talks to the Online CA to generate certificates for authenticated users.
    • Online CA : is a Certificate Authority running on an HSM. This service (although called online) is only directly accessible to the Delegation Server in front of it.
    • WAYF : an IdP / SP Proxy with an internal filter for accepting authentication sources directly. This gives full control for RCauth.eu over the eligibility of IdPs.
  • Purple components [many] represent the different authentication sources that RCauth.eu is accepting (or planning to accept in the near future).

Flow

The flow of this setup is equivalent to the flow described before, with the only small difference that the WAYF/IdP component of the flow (corresponding to the WAYF (IdP/SP Proxy) of RCauth.eu) is now moved under the same security domain as the Delegation Server.

Using our own WAYF (IdP/SP Proxy) means we also introduce an additional redirect in the flow. This, however, can be automated by using an IdP hint. An IdP hint, containing a URL-encoded entity ID of the home IdP of the user, can be sent by the Service Provider Portal (Science Gateway) upon first contacting the Master Portal for a proxy. The IdP hint is sent along to the WAYF (IdP/SP Proxy) which will verify it to be a valid authentication source, and automatically redirect the user to his preferred IdP. This hides some of the complexities of the setup from the user, since they are no longer required to choose their home IdP in case they are already authenticated at the Service Provider Portal (Science Gateway). This functionality normally relies on the cooperation of the Service Provider Portal (Science Gateway), who is responsible of constructing and sending a valid IdP hint for its users in the first place. Alternatively, for large communities, a dedicated MasterPortal can be set up, that constructs the IdP hint.

Credential Lifetimes

Note! Although this setup and its underlying software is fully compatible with the PUSPs scenario, the RCauth.eu CA is only producing end entity certificates (EEC).

We distinguish three different type of credentials in our setup:

  • End Entity Certificates (EEC) are produced by the Delegation Server for authenticated users. The maximum lifetime of these credentials is 11 days.
  • Long Lived Proxy Certificates are produced by the Master Portal from the EEC retrieved from the Delegation Server and they are stored in the Credential Store. The lifetime of these proxies will match the lifetime of the EEC they are based on, and hence will also be 11 days.
  • Short Lived Proxy Certificates are produced by the Master Portal from the stored Long Lived Proxy Certificate. They are released to the VO Portals (Science Gateways) and the lifetime of these proxies is decided based on the lifetime value requested by the latter. In case no lifetime value is requested, it defaults to 12 hours.
Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=RCauth.eu_and_MasterPortal_overview&oldid=10702"