WLCG Pilot Description
The Worldwide LHC Computing Grid (WLCG) project is a global collaboration of more than 170 computing centres in 42 countries, linking up national and international grid infrastructures. The mission of the WLCG project is to provide global computing resources to store, distribute and analyse the ~50 Petabytes of data expected annually, generated by the Large Hadron Collider (LHC) at CERN on the Franco-Swiss border.
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
Requirements
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:
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):
- Integration with CERN SSO (as an option) and CERN’s Identity Vetting DB
- Users should not have to request or manage X.509 certificates or other identity tokens themselves in addition to their login session (required token should be provisioned transparently), i.e. token translation, token provisioning
- AuthZ attribute selection by the user must be possible (i.e. active role selection)
- Step-up for critical services e.g. 2FA