RCauth.eu and MasterPortal overview

From PDP/Grid Wiki
Revision as of 14:47, 22 July 2016 by Tamasb@nikhef.nl (talk | contribs) (rcauth page draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.

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. We are expecting to see a few of these services.
  • Red components [few] correspond to the Master Portal.
    • 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 a small difference between steps 4 and 5. Since RCauth.eu is using its own WAYF (IdP/SP Proxy) there will be an additional redirect between steps 4 and 5 that will take care of redirecting the user to his selected RI (Research Infrastructure) or IdP for authentication. From the point of view of the flow this additional redirect 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.