Difference between revisions of "Fedcloud-tf:WorkGroups:Federated AAI:per-user sub-proxy"
(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 | 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 End-Entity Certificate (EEC) | The Per-User Sub-Proxy (PUSP) and End-Entity Certificate (EEC) must satisfy the following requirements: | ||
<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> | |||
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. | |||
Software | == 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. For EGI FedCloud, this is the Perun service. The AC is issued for a specific DN. The AC 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. 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. | 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 17: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:
- 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.
- The PUSP is RFC 3820 compliant, i.e. no legacy GT2 or GT3 proxies
- The PUSP is the first proxy delegation
- The same user of the portal will always have the same PUSP DN
- 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.