Difference between revisions of "Fedcloud-tf:WorkGroups:Federated AAI:per-user sub-proxy"

From EGIWiki
Jump to: navigation, search
(Processing expectations)
(Suspension and revocation of the PUSP users)
Line 57: Line 57:
 
=== Suspension and revocation of the PUSP users ===
 
=== 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 <tt>lcmaps_robot_ban_dn</tt> plugin. The DN to ban MUST be the complete PUSP DN such as <pre>"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=user:jdoe"</pre>
+
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 [https://wiki.nikhef.nl/grid/Lcmaps-plugins-robot lcmaps-plugins-robot] package includes a <tt>lcmaps_robot_ban_dn</tt> plugin. The DN to ban MUST be the complete PUSP DN such as <pre>"/DC=org/DC=terena/DC=tcs/O=Nikhef/OU=Robot/CN=Robot - Marvin/CN=user:jdoe"</pre>

Revision as of 12:45, 13 February 2015

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 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, generate non-PUSP proxy credentials or direct authenticating.

Processing expectations

Software is expected to follow the following rules:

If any of conditions 1--3 are not met then the software MUST NOT treat the proxy as a PUSP. Instead the software SHOULD treat the proxy as an normal proxy issued by the EEC.

Software may assume conditions 4 and 5 are honoured without independently verifying them.

To allow existing deployed software to operate with PSUP, software MAY treat a client authenticating with a valid PUSP credential as a client authenticating with a normal proxy credential issued by the EEC. However, such behaviour may have accounting and security implications that should be understood.

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"