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. A common example is where a web portal (e.g., a scientific gateway) somehow identifies its user and wishes to authenticate as that user when interacting with EGI resources. This is achieved by creating a proxy credential from the robot credential with the certificate containing user-identifying information in its additional CN field. The user-identifying information 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 character. 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 identified user will always have the same PUSP DN
5. No two distinct identified users will have the same PUSP DN.

A robot EEC that generates PUSP credentials SHOULD NOT be used for any other purpose; for example, it should not be used to generate non-PUSP proxy credentials and should not be use for direct authenticating.

Processing expectations

Software MUST verify conditions 1..3 above before accepting a PUSP.

Software MUST NOT accept certificate chain as authenticating the identified user if any of the conditions 1..3 fail.

Software SHOULD treat all proxy certificates that fail any of conditions 1..3 as authenticating the end-entity (i.e., as a normal proxy).

Software SHOULD assume conditions 4 and 5 are honoured.

Software MUST establish a chain-of-trust leading back to a trusted CAs.

Software MUST use CRLs information and/or OCSP to verify that none of the certificates in the chain-of-trust have been revoked.

Software SHOULD ensure any CRL information is not outdated.

Software MUST treat the user-identifying information (the final CN in the PSUP DN) as an opaque string and MUST NOT attempt to decode it. Partial matching is considered a form of decoding.

To allow currently deployed software to operate with PSUP, software MAY identify a client authenticating with a valid PUSP certificate as the issuing robot. However, such behaviour may have accounting and security implications that should be understood.

To match some specific identified user, the complete PUSP DN must be matched.

For example the following grid-mapfile matches a specific identified user as jdoe_local_user and all other users as portal_pool_users:

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

User identity and VO information

Membership of Virtual Organisations (VO) is handled by acquiring an Attribute Certificate (AC) from a VO-membership service. Membership is described in terms of one or more Fully Qualified Attribute Names (FQANs), each of which describe the user's membership of a group or some role within a group. VOMS, Perun and UNITY are examples of software that implement this VO-membership service. The AC is issued for and linked to a specific robot DN. The AC is embedded within the PUSP proxy certificate.

In the current architecture, the robot is a member of a VO. Therefore, any PUSP credential always identifies the agent as a member of that VO and can inherit any and all the roles of the robot. Therefore, the following conditions hold:

The robot MUST have knowledge of which users are members of its VO.

The robot MUST ensure that a PUSP is only issued for members of the VO. The robot MUST request an AC with only those roles available to all its users, if any. The robot MAY allow users to choose with FQAN is asserted first in the AC.

User suspension and revocation

There are two distinct levels of suspension and revocation, first on the level of the robot certificate, secondly on the level of the identified user.

Suspension and revocation of the Robot certificate

Motivation: stop all activity issued by the robot

Trigger: it is believed likely that the robot private key or the software environment using the private key has become compromised.

Action: the robot DN is placed on the central suspension list (e.g., ARGUS) and the certificate is revoked by the CA.

Note that, in this case, suspending individual PUSP DNs is unnecessary.

Suspension and revocation of the PUSP users

Motivation: want to stop all activity of a single identified user.

Trigger: it is believed likely that...

• the mechanism with which the identified user authenticates has become compromised (e.g., password was guessed),
• the user's environment has become compromised (e.g., trojan software),
• the user is acting outside VO's acceptable use policy,
• the user is introducing too great a load and attempts to contact them have failed.

Action: the robot blocks access for this user. Central suspension lists (e.g., ARGUS) are updated to include the identified user's PUSP DN. Individual services MAY block the PUSP DN.

For example, the lcmaps-plugins-robot package includes a lcmaps_robot_ban_dn plugin. The DN to ban MUST be the complete PUSP DN such as:

"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=user:jdoe"