Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

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

From EGIWiki
Jump to navigation Jump to search
(Created page with "= The per-user sub-proxy = The purpose of a per-user sub-proxy is to allow a robot certificate to identify that it is operating on behalf of some specific user.  This is ac...")
 
(Extensive rewrite with extra additional requirements and clarifications.)
Line 1: Line 1:
= The per-user sub-proxy =
= The per-user sub-proxy =


The purpose of a per-user sub-proxy is to allow a robot certificate to identify that it is operating on behalf of some specific user.  This is achieved by creating a proxy certificate such that:
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.


*The same user of the portal will always have the same DN
== Requirements ==
*All other users will have a different DN


The End-Entity Certificate (EEC) is the certificate issued by the CA. 
The Per-User Sub-Proxy (PUSP) and End-Entity Certificate (EEC) must satisfy the following requirements:


For the per-user sub-proxy certificate to be valid, the following conditions must hold:
<ol>
<li> The EEC is a valid robot certificate:
<ul>
<li> 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
<li> or its DN matches the regular expression "<tt>.*/CN=[rR]obot[^[:alnum:]]+</tt>" 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.
</ul>
<li> The PUSP is RFC 3820 compliant, i.e. no legacy GT2 or GT3 proxies
<li> The PUSP is the first proxy delegation
<li> The same user of the portal will always have the same PUSP DN
<li> The PUSP DN must be unique: no two users will have the same PUSP DN
</ol>


*The EEC&nbsp;must be a robot certificate
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.
*There must be exactly one per-user sub-proxy certificate
*The per-user sub-proxy certificate must be the first proxy after the EEC.


If these conditions are not satisfied then software must process requests as if the EEC&nbsp;issued the request.
The reverse cannot be enforced. Hence, if the conditions 1-3 are met, the proxy MAY be treated as a PUSP.


The robot credential used to issue per-user sub-proxy credentials must not be used for any other purpose.
A robot EEC used for producing PUSPs SHOULD ''not'' be used for other purposes, i.e. SHOULD ''not'' also produce 'normal' proxies.


Software must verify the complete chain [all proxies; EEC and CA(s)]
== 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 ==
== User identity and VO information ==


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


Currently, the robot is a member of a VO.&nbsp; Any per-user sub-proxy is then automatically a member of that VO.&nbsp; 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.
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.

Revision as of 16:22, 12 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 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.