Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

WLCG Pilot Description


Worldwide LHC Computing Grid


- the Computing Infrastructure for High Energy Physics 

Image Added

Pilot Description

WLCG has been operating a distributed computing infrastructure for the past 15 years. User authentication and group management is based on x509 certificates, with authorisation conveyed in VOMS Proxy certificates. This is no longer considered good practice, both for user experience and for infrastructure sustainability since the community at large is moving to OAuth2.0 token based authentication and authorisation models.

This pilot activity aims to identify and enhance an existing AAI service to suit the requirements of the High Energy Physics community. The requirements focus on aspects currently not included in AAIs, a sample of which are included here:

  • A user-friendly workflow to provision authorisation tokens in the user's local environment for command line activities. The majority of physicists time is spent submitting "jobs" (analysis code) from a terminal and it is essential that limited browser interaction is required for authentication/authorisation.
  • Integration with existing infrastructure for a smooth transition. Token translation to and from certificates will be essential for backwards compatibility. The existing database of identity vetting must also be leveraged. 
  • Development of a shared JWT profile for the wider physics community

A priority for WLCG was not to reinvent the wheel, following the FIM4R recommendation to re-use shared components. Two solutions have been identified as possibilities and are currently undergoing developments; EGI-Check-in and INDIGO IAM. Both solutions have multiple reasons for enhancing their services and as such the decision was made to continue with the two options in parallel.

The goal is to provide a self-contained AAI pilot solution that enables token based authentication and authorisation for WLCG. The two pilot services will be developed in parallel, assessed and a recommendation made to the community. Such a solution will be of wider benefit to user communities also looking to move away from x509 based authentication and authorisation, and developments in INDIGO IAM and EGI-Check-in will be relevant for a larger audience.


The test phase for this pilot will begin in December where an analysis will be made of the pilot implementations against WLCG Requirements. This will be a face-to-face analysis.

It is hoped that this pilots will:

  • Allow a proposal to be made to the WLCG Management Board
  • Provide a AAI solution that fulfils the requirements needs and is maintained in collaboration with the wider community


Image Added

The goal of the AARC2 WLCG pilot is to demonstrate the usage of WLCG Grid services by users through eduGAIN without the need to make use of personal X.509 certificates, which are the current way of authentication for WLCG users. A wide discussion has been carried out within the WLCG Authorization Working Group to define the community requirements about the architecture of the future AAI infrastructure for the WLCG Grid. The AARC pilot on WLCG has been liaising with the WLCG AuthZ WG to tune the pilot around the main steps required to provide a demonstration of such a use case.

The main goal for this pilot can thus be summarised as follows: “Demonstrate a pilot solution for a researcher without a certificate to register in a WLCG VO and access a grid service”, while at the same time:

  • Introducing the minimal required new components to allow smooth user experience
    • Central IdP/SP proxy
    • Token Translation Service
    • Attribute Authority
  • Managing authentication and authorization to comply with WLCG requirements and standards
    • HR-db integration
    • Acceptable level of assurance in line with IGTF profiles
  • Minimizing the number of new developments required by WLCG Services


The WLCG community is currently operated by means of Virtual Organisations, which represent community of users belonging to large, usually world-wide groups, with similar needs and requirements in terms of Job processing and Data management. The current AAI makes use of the VOMS (Virtual Organisations Management System) server, which stores relevant user attributes to issue an X.509 temporary proxy certificate acting on behalf of the user towards access to resources. The VOMS server adds to the X.509 proxy an extension which specifies the user VO affiliation, and her role within the VO. Based on this extension authorisation decisions are taken by the Grid infrastructure.

An overall assessment of the requirements by WLCG about a new SAML-based AAI infrastructure has brought the following list of items:

  • VO Membership Management
    • Attributes? VO ID, ID of credential, Name, Email, Authorization
    • Support multiple federated credentials & their linkage
    • Active role selection
    • Token management achievable by the standard user
  • Service Requirements
    • Attributes? Authorization plus traceability / Groups/Roles
    • Ease of implementation
    • Use standard approaches
    • Token integrity and validity verifiable without connecting to the issuer
    • For non-web, users should not have to manage identities in addition to their login session
  • General
    • Support for fine grained suspension
    • Smooth transition from current X509-based to token-based AAI

An overall AARC BPA compliant architecture has been proposed to satisfy the needs of WLCG AAI, which consist of a central proxy element:

Image Removed

The core component of the proposed architecture is the proxy element. The proxy will see CERN SSO as an IdP, and further plug additional Authentication Methods.

One implementation option for the IdP/SP proxy is the the Indigo IAM, which represents a complete solution with south-bound OIDC, X.509 and SAML and north-bound OIDC/OAuth2.

Another approach that will be evaluated within this pilot is the EGI CheckIn service, acting as an IdP/SP proxy, implemented in SimpleSAMLphp, and already integrated to the COmanage attribute authority.

A careful analysis of the existing components and the required overall provided functionality has shown the following main gaps (for both options):