Difference between revisions of "Usage of the per user sub proxy in EGI"
(Created page with "{{Template:Community_Engagement}} {{TOC_right}} Category:Community Engagement =Per-User Sub-Proxies=") |
|||
Line 3: | Line 3: | ||
[[Category:Community Engagement]] | [[Category:Community Engagement]] | ||
=Per-User Sub-Proxies= | =The Per-User Sub-Proxies= | ||
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 proxy certificate containing user-identifying information in its additional proxy 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: | |||
<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 non-slash character. 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> If the same user enters via the same portal, he must get the same PUSP DN | |||
<li> No two distinct identified users will have the same PUSP DN. | |||
</ol> | |||
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. |
Revision as of 17:55, 20 October 2015
Engagement overview | Community requirements | Community events | Training | EGI Webinars | Documentations |
The Per-User Sub-Proxies
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 proxy certificate containing user-identifying information in its additional proxy 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:
- 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 non-slash character. 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
- If the same user enters via the same portal, he must get the same PUSP DN
- 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.