Difference between revisions of "RCauth.eu and MasterPortal overview"

From PDP/Grid Wiki
Jump to navigationJump to search
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
= RCAuth.eu  =
+
= 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 [https://www.rcauth.eu/ RCAuth.eu] website. Other RCAuth.eu resources:
+
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 [https://www.rcauth.eu/ RCauth.eu] website.
  
* [http://rcauth.eu/ RCauth.eu Home Page]
+
Further documentation can be found at [[RCauth.eu_and_MasterPortal_documentation | RCauth.eu and MasterPortal documentation]].
* [https://wiki.geant.org/display/AARC/RCauth.eu-CILogon-like-TTS-pilot RCauth.eu-CILogon-like-TTS-pilot]
 
* [https://wiki.geant.org/display/AARC/Models+for+the+CILogon-like+TTS+Pilot Sustainability Models for the CILogon-like TTS Pilot]
 
  
If you are interested to know where RCAuth.eu came from, please check out the general architecture description of out [[AARC_Pilot_-_Architecture | AARC Pilot]].
+
= Self-Registration =
  
= Self-Registration =
+
In order to register a Master Portal to RCauth.eu, you can point your browser to the [https://pilot-ca1.rcauth.eu/oauth2/register 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.
  
In order to register a Master Portal to RCAuth.eu, you can point your browser to the [https://pilot-ca1.rcauth.eu/oauth2/register 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!
+
'''Note:''' the new client still needs to be approved by an RCauth operator before actual use: for this you will need to fill in the Master Portal Signup form (see [https://rcauth.eu/ the RCauth webpage, bottom right-hand corner]).
  
 
= Architecture =
 
= Architecture =
Line 20: Line 19:
  
 
* <span style="color:#7EA6E0">'''Blue component'''</span> [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.
 
* <span style="color:#7EA6E0">'''Blue component'''</span> [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 [https://www.nikhef.nl/~msalle/oidc_getproxy_demo_source.php demo portal] (written in php). This is a good starting point to learn how to interface with the Master Portal.
+
** ''Example Portal'' : As an example, we provide several [https://rcdemo.nikhef.nl/ demo portals] (written in php). These are a good starting point to learn how to interface with the Master Portal, in particular the [https://rcdemo.nikhef.nl/demobasic/ Basic demo].
* <span style="color:#EA6B66">'''Red components'''</span> [few] correspond to the [[AARC_Pilot_-_Architecture | Master Portal]]. We are expecting to see a few of these services.
+
* <span style="color:#EA6B66">'''Red components'''</span> [few] correspond to the [[RCauth.eu_and_MasterPortal_architecture | 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.
 
** ''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.
 
** ''Credential Store'' : is a MyProxy server used by the Master Portal to actually store the user proxies.
Line 32: Line 31:
 
==== Flow ====
 
==== Flow ====
  
The flow of this setup is equivalent to the flow described [[AARC_Pilot_-_Architecture#Detailed_Flow | 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.
+
The flow of this setup is equivalent to the flow described [[RCauth.eu_and_MasterPortal_architecture#Detailed_Flow | 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.
+
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 =
 
= Credential Lifetimes =
  
'''Note!''' Although this setup is fully compatible with [[PUSP from MyProxy | PUSPs]], RCauth.eu is only producing end entity certificates (EEC).
+
'''Note!''' Although this setup and its underlying software is fully compatible with the [[PUSP from MyProxy | PUSPs]] scenario, the RCauth.eu CA is only producing end entity certificates (EEC).
  
 
We distinguish three different type of credentials in our setup:
 
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'''.   
 
* 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'''.
+
* 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 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'''.
+
* 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'''.

Latest revision as of 09:46, 24 January 2020

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.

Further documentation can be found at RCauth.eu and MasterPortal documentation.

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: for this you will need to fill in the Master Portal Signup form (see the RCauth webpage, bottom right-hand corner).

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.