Alert.png 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 @

Usage of the per user sub proxy in EGI

From EGIWiki
(Redirected from EGI AAI)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
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.

Example of a Per-User Sub-Proxy (PUSP):

subject   : /C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: EGI Training Service - XXXXX/CN=eToken:test1/CN=1286259828
issuer    : /C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: EGI Training Service - XXXXX/CN=eToken:test1
identity  : /C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: EGI Training Service - XXXXX
type      : RFC3820 compliant impersonation proxy
strength  : 1024
path      : /home/XXXXX/proxy.txt
timeleft  : 23:59:15
key usage : Digital Signature, Key Encipherment, Data Encipherment
=== VO extension information ===
VO        :
subject   : /C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: EGI Training Service - XXXXX
issuer    : /DC=org/DC=terena/DC=tcs/OU=Domain Control Validated/
attribute : /
timeleft  : 23:59:17
uri       :

The EGI Credential Translator Pilot Service

EGI adopted the e-Token server [1] as a pilot for a central credential translator system based on PUSPs. In a nutshell the eToken server is a standard-based solution developed by and hosted in INFN Catania for central management of robot credentials and provisioning of digital proxies to get seamless and secure access to computing e-Infrastructures supporting the X.509 standard for Authorisation.

The e-Token server uses the standard JAX-RS framework [2] to implement RESTful Web services in Java technologies and provides, to the end-users, portals and new generation of Science Gateways, a set of REST APIs to generate PUSPs given a unique identifier. PUPS are usually generated starting from standard X.509 certificates. These digital certificates have to be uploaded into one of the secure USB smart cards (e.g. SafeNet Aladdin eToken PRO 32/64 KB) and plugged in the 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 two available e-Token Server instances for availability and realibility reasons:


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/[Robot Certificate ID]?voms=[VO]:/[VO]&proxy-renewal=[true|false]&disable-voms-proxy=[true|false]&rfc-proxy=[true|false]&cn-label=eToken:[user unique identifier]
  • Robot cetificate ID: it is the ID of your robot certificate in the e-Token server. It will be generated after the setup of your robot into the e-Token Server.
  • VO: the VO you want to use to perform any action on the EGI infrastructure. The robot certificate must be a member of this VO.
  • proxy-renewal: this option is used to enable (true) or disable (false) the automatic registration of a long-term proxy into a MyProxy Server.
  • disable-voms-proxy: this option is used to generate plain (true) or VOMS proxy certificate (false).
  • rfc-proxy: this option is used to generate standard RFC proxies (true) or legacy proxies (false).
  • cn-label: this option is used to generate a PUSP for the given unique identifier.

below an example:

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


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:
  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 machine/service that will take care of PUSP generation and management should respect the following rules:

  1. Documented response procedures in case of incidents (that are periodically tested).
  2. A listed/accredited CSIRT team.
  3. Internal risk assessment and an actuarial team to calculate the effective risk


[1] Valeria Ardizzone, Roberto Barbera, Antonio Calanducci, Marco Fargetta, E. Ingrà, Ivan Porro, Giuseppe La Rocca, Salvatore Monforte, R. Ricceri, Riccardo Rotondo, Diego Scardaci, Andrea Schenone: The DECIDE Science Gateway. Journal of Grid Computing 10(4): 689-707 (2012)

[2] Java API for RESTful Web Services (JAX-RS):