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 "Usage of the per user sub proxy in EGI"
| Line 24: | Line 24: | ||
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. | 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. | ||
== The EGI Credential Translator == | |||
EGI adopted the e-Token server, a service developed by and hosted in INFN Catania, as a pilot for a central credential translator system based on PUSPs. The e-Token server provides users with a simple REST API to generated PUSPs given a unique identifier. The PUSPs are generated starting from a robot certificate that should be previously uploaded into the e-Token server. | |||
Revision as of 18:01, 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.
The EGI Credential Translator
EGI adopted the e-Token server, a service developed by and hosted in INFN Catania, as a pilot for a central credential translator system based on PUSPs. The e-Token server provides users with a simple REST API to generated PUSPs given a unique identifier. The PUSPs are generated starting from a robot certificate that should be previously uploaded into the e-Token server.