Usage of the per user sub proxy in EGI

From EGIWiki
(Redirected from EGI AAI)
Jump to: navigation, search
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=user:test1/CN=1286259828
issuer    : /C=IT/O=INFN/OU=Robot/L=Catania/CN=Robot: EGI Training Service - XXXXX/CN=user: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:

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=user:[user 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):

Personal tools