Fedcloud-tf:WorkGroups:Federated AAI:per-user sub-proxy

The per-user sub-proxy

The purpose of a per-user sub-proxy (PUSP) is to allow identification of the individual users that operate using a common robot certificate, e.g. the users of a scientific gateways running from portals. This is achieved by creating from the robot certificate a proxy certificate containing user-identifying information in its additional CN field. This may be pseudo-anonymised where only the portal knows the actual mapping.

Requirements

The Per-User Sub-Proxy (PUSP) and End-Entity Certificate (EEC) must satisfy the following requirements:

1. The EEC is a valid robot certificate:
   • it either contains OID 1.2.840.113612.5.2.3.3.1, see https://www.eugridpma.org/objectid/?oid=1.2.840.113612.5.2.3.3.1
   • or its DN matches the regular expression ".*/CN=[rR]obot[^[:alnum:]]+" i.e. containing a CN field which starts with robot or Robot and is followed by a non-alphanumerical string. see https://www.eugridpma.org/guidelines/robot/ section 3.
2. The PUSP is RFC 3820 compliant, i.e. no legacy GT2 or GT3 proxies
3. The PUSP is the first proxy delegation
4. The same user of the portal will always have the same PUSP DN
5. The PUSP DN must be unique: no two users will have the same PUSP DN

If one of the conditions 1-3 is not met, the software MUST not treat the proxy as a PUSP but as an ordinary proxy issued by the EEC.

The reverse cannot be enforced. Hence, if the conditions 1-3 are met, the proxy MAY be treated as a PUSP.

A robot EEC used for producing PUSPs SHOULD not be used for other purposes, i.e. SHOULD not also produce 'normal' proxies.

Verification

Software SHOULD consider only the first three conditions above, i.e. software SHOULD not assume a specific form of the extra CN=... field. When matching the subject DN with entries in e.g. a grid-mapfile, the match MUST be done on the complete PUSP DN, in order to match the robot DN and the PUSP extra CN field together, where wild-cards can be used.

Example grid-mapfile entry:

"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=eToken:jdoe" jdoe_local_user
"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=eToken:*" .portal_pool_users

In addition, the software MUST verify the entire certificate chain in the normal way, against known and accepted CA distributions and using CRLs and/or OCSP.

User identity and VO information

Membership of Virtual Organisations (VO) is handled by acquiring an Attribute Certificate (AC) from a VO-membership service.  For EGI FedCloud, this is the Perun service (IS THIS CORRECT?).  The AC is issued for and linked to a specific robot DN.  The AC is embedded within a proxy certificate to form a voms proxy certificate.

Currently, the robot is a member of a VO. Any per-user sub-proxy is then automatically a member of that VO and inherits all the roles of the robot. This means that the portal must have some way (outside of Perun) of discovering whether or not a user is a member of a VO and that the robot MUST not get any specific roles which are not suitable for all the users.