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

From EGIWiki
Revision as of 11:31, 13 February 2015 by Msalle (talk | contribs) (Add section on suspension, need information on handling within Perun)
Jump to: navigation, search

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:
  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=user:jdoe" jdoe_local_user
"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=user:*" .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.

User suspension and revocation

There are two distinct levels of suspension and revocation, first on the level of the gateway/portal or robot certificate, secondly on the level of the actual (portal) user.

Suspension and revocation of the Robot certificate

In case the portal or its certificate has been compromised, the robot certificate can be put on the central suspension list and its own DN will be blocked in the normal way. Further more, its certificate should be revoked and put on the next CRL of the issuing CA. Note that only suspending all the PUSP, i.e. something like "/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=*", is not sufficient nor necessary.

Suspension and revocation of the PUSP users

In case an individual user must (temporarily) be denied access, first access to the portal must be blocked for this user. Due to the nature of proxy certificates, it is not possible or necessary to revoke any certificates. However, the PUSP DN can be blocked via suspension software that has support for PUSP. 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"