RCauth.eu and MasterPortal overview

From PDP/Grid Wiki
Revision as of 10:40, 7 September 2016 by Tamasb@nikhef.nl (talk | contribs)
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. Other RCAuth.eu resources:

If you are interested to know where RCAuth.eu came from, please check out the general architecture description of out AARC Pilot.

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. Use this in your Master Portal configuration!

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 a demo portal (written in php). This is a good starting point to learn how to interface with the Master Portal.
  • 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 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 he is no longer required to choose his home IdP in case he is already authenticated at the Service Provider Portal (Science Gateway). This functionality completely 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.

Credential Lifetimes

Note! Although this setup is fully compatible with PUSPs, RCauth.eu 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, which in this case will be 11 days.
  • Short Lived Proxy Certificates are produced by the Master Portal from the stored Long Lived Proxy Certificate and they are released to the Portals (Science Gateways). The lifetime of these proxies is decided based on the lifetime value sent by the Portals. In case no lifetime value is requested, it will default to 12 hours.
Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=RCauth.eu_and_MasterPortal_overview&oldid=10210"