Usage of the per user sub proxy in EGI

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:

1. 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.
2. The PUSP is RFC 3820 compliant, i.e. no legacy GT2 or GT3 proxies
3. The PUSP is the first proxy delegation
4. If the same user enters via the same portal, he must get 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, it should not be used to generate non-PUSP proxy credentials and should not be use for direct authenticating.

The EGI Credential Translator Pilot Service

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. The e-Token server was conceived for providing a credential translator system to Science Gateways and Web Portals that need to interact with the EGI infrastructure (and in general with any e-Infrastructure).

If you want to use the EGI Credential Translator pilot service you have to perform the following preliminary steps:

• Get a robot certificate from your national CA
• Contact the EGI User Community Support Team (ucst@egi.eu) to store your robot certificate in the e-Token server
• Provide a static IP address that will be used to interact with the e-Token Server
• After the setup is completed, UCST will send you an identifier of your robot in the e-Token Server. You have use this identifier to interact with the e-Token server

Use the EGI Credential Translator Pilot Service

There are three available e-Token Server instances for availability and realibility reasons:

• etokenserver.ct.infn.it
• etokenserver2.ct.infn.it
• etokenserver3.ct.infn.it

These instances are accessible only from a list of IP addresses (see section above).

The following rest API is available to get a PUSP given a unique identifier:

https://[eToken Server instance]:8443/eTokenServer/eToken/[]?voms=[VO]:/[VO]&proxy-renewal=false&disable-voms-proxy=false&rfc-proxy=true&cn-label=user:[user unique identifier]

below an example:

https://etokenserver2.ct.infn.it:8443/eTokenServer/eToken/27br90771bba31acb942efe4c8209e69?voms=training.egi.eu:/training.egi.eu&proxy-renewal=false&disable-voms-proxy=false&rfc-proxy=true&cn-label=user:test1