RCauth Delegation Server & MasterPortal - Credential Lifetimes

From PDP/Grid Wiki
Revision as of 13:45, 5 September 2019 by Msalle@nikhef.nl (talk | contribs) (→‎End Entity Certificate)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Introduction

The RCauth and MasterPortal scenario deals with serveral different user and proxy certificates. The credential released to the VO Portal (Science Gateway) is a proxy certificate chain containing:

  • a short lived RFC3820 proxy certificate (optionally with VOMS extensions)
  • a long lived RFC3820 proxy certificate
  • an end entity certificate (EEC) signed by the RCauth CA.

All three certificates can be created with a different lifetime, therefore configuring those lifetimes can be confusing. This page gives a detailed explanation of every lifetime configuration you might encounter in the setup, including the configuration location, default value and function.

  • The entries marked below with red are client side input parameters usually used in a request for a credential.
  • The entries marked below with blue are server side maximum values used to enforce the actual lifetimes.

Short Lived Proxy

The lifetime of a Short Lived Proxy Certificate is determined by the following set of configurations.

Component Sub-Component Name Default Location Description
Client Portal (e.g. Science Gateway) - proxylifetime - /getproxy request Client requested lifetime value.
SSH host - lifetime 12h /usr/local/sbin/myproxy_cmd script or ansible template. Default lifetime of proxies returned in the SSH flow.
SSH host - maxlifetime 72h /usr/local/sbin/myproxy_cmd script or ansible template. Maximum lifetime of proxies returned in the SSH flow.
Master Portal MP Server defaultLifetime 12h MP Server configuration In case the proxylifetime value is missing from the /getproxy request issued by the client, this value is used to request a short lived proxy.
Master Portal MP Server max_proxy_lifetime - tolerance (11d - 1d)
i.e. 10d
MP Server configuration Used within LifetimeValidator for validating the requested proxy lifetime value. Note: These values are only used for validation and they do not SET the actual effective proxy lifetime. The max_proxy_lifetime value here should match the value of the lifetime configuration with the same name in the Credential Store, see next row.
Master Portal Credential Store max_proxy_lifetime 11d Credential Store configuration Server side maximum enforced by the MyProxy server on every released proxy. This should match the value of the MP Server configuration with the same name, see previous row.

Long Lived Proxy

The lifetime of a Long Lived Proxy Certificate is determined by the following configuration.

Component Sub-Component Name Default Location Description
Master Portal MP Client lifetime 11d OA4MP Client configuration This is a standard OA4MP Client configuration used for requesting a certificate lifetime. In the context of the Master Portal this value will determine the lifetime of both the long lived proxy and the requested end entity certificate.

End Entity Certificate

The lifetime of an End Entity Certificate (EEC) is determined by the following configuration. Note that the lifetime configuration in the first row affects both Long Lived Proxy Certificate and EEC, which is a design choice of the MasterPortal.

Component Sub-Component Name Default Location Description
Master Portal MP Client lifetime 11d OA4MP Client configuration This is a standard OA4MP Client configuration that is used as a requested certificate lifetime. In the context of the Master Portal this value will determine the lifetime of both long lived proxy and requested end entity certificate.
Delegation Server Delegation Server - 10d Hardcoded by OA4MP In case the lifetime value is missing from the /getcert request issued by the Master Portal, the lifetime of the requested certificate will default to this value.
Delegation Server Online CA MAX_LIFETIME 11d sysconfig value of the eToken-ca Server side maximum enforced by the back-end CA on every released certificate.