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.

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: you can find detailed instruction here. If you have any trouble to complete this step (e.g. a national CA does not exist in your country, your CA does not release robot certificate, etc.) contact the EGI User Community Support Team that can assist you.
• The robot certificate has to be registered in the VO you are willing to use. The complete EGI VO list is available here.
• Contact the EGI User Community Support Team to store your robot certificate in the e-Token server.
• Provide the EGI User Community Support Team with a static IP address that will be used to interact with the e-Token Server.
• After the setup is completed, the EGI User Community Support Team will send you an identifier of your robot in the e-Token Server. You will have to 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 pre-defined IP addresses. You have to provide EGI with the IP address of the machine you are going to use to interact with the e-Token Server (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

Generate and manage PUSPs locally

You can also decide to locally generate PUSPs in your Science Gateway or Portal. In this case, you have to carefully take care of the security of your system since you are managing a credential creation process.

To generate the PUSPs by yourself, you can use the script available at [this link|https://ndpfsvn.nikhef.nl/viewvc/mwsec/trunk/lcmaps-plugins-robot/tools/]

Requirements

This section details the requirements you have to satisfy whether you decid to generate and manage PUSPs locally.

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.