Versions Compared

Key

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

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 EGI-Check-in pilot is being driven by AARC, with RCAuth integration covered as a collaboration between the developers behind EGI-Check-In and INDIGO IAM.

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.

More information can be found here: https://hackmd.web.cern.ch/s/rkyic3vtm 

Pilot goals

The pilot goals are to:

  • Support the development of shared AAI components to meet the requirements of WLCG
  • Contribute AARC best practices to definition of the JWT Profile for token content

Description

This pilot is effectively a full implementation of an advanced AAI in line with the AARC BPA. It should cover all aspects of a robust AAI, including membership management and token provisioning.

WLCG would like to reuse software and contribute to limiting the number of disparate deployments out there, but no tools currently fulfil all of our requirements. There was sufficient interest from EGI-Check-in and INDIGO IAM to enhance their software. The work on EGI-Check-in is officially supported by AARC.

Components

The components are as follows:

ComponentDescriptionWhy did we choose it?Link
RCAuthToken Translation. Used to generate x509 certificates for access to legacy servicesEU wide, sustainable infrastructure componenthttps://rcauth.eu
VOMSAttribute Authority & Membership Management. Legacy authorisation database for WLCG, must be integrated for backwards compatibilityPre-existing. Backwards compatibilityhttps://italiangrid.github.io/voms/
CERN HR DBAttribute Authority. CERN's source of identity vetting informationPre-existing. Backwards compatibilityN/A
INDIGO-IAMOne option for the proxy and membership management componentImplements multiple components, easier maintenance. Product used by other communities.https://www.indigo-datacloud.eu/identity-and-access-management
EGI-Check-inThe second option for the proxy and membership management componentImplements multiple components, easier maintenance. Product used by other communities.https://www.egi.eu/services/check-in/


Architecture

The architecture includes every component of the AARC BPA. 

Simplified version:

Image Added


AARC BPA version:

Image Added


Use Cases

Videos for the AARC supported pilot for EGI-Check-in are available at link

User links x509 certificate with federated credentials

StepScreenshots
User registers with the system using a federated account

Image Added

Image Added

Image Added

Image Added


Image Added


User associates x509 user certificate with their account

Image AddedImage Added

User submits a physics job

StepScreenshot (TBC)
User follows registration flow above
User requests token from command line (Device Code Flow)

Image Added

User submits a job in the normal way

Demo EGI Check-in videos

The various functionalities provided by EGI Check-in are available through mini videos demonstrating the below functionalities/flows:

  • Trying to add a non-WLCG experiment member into the system
  • Adding a WLCG Experiment member into the system( Create the user, obtain an RCAuth certificate, register into VOMS)
  • Group management
  • HRDB periodic syncing
  • Invite multiple people via email from an administrator's account
  • SSH key authentication for RCAuth proxy retrieval
  • Token exchange and device code  


Visit the following link to view.


Further information

AARC's specific role in this pilot is to coordinate the efforts, ensure that AARC recommendations are considered and to support the enhancement of EGI-Check-in. 

Was BPA useful to achieve this results? WLCG is looking at two existing AAI solutions that are broadly in line with the BPA already.

Sustainability? The aim of this pilot is to provide a recommendation for WLCG to deploy a BPA compliant AAI. This will be physically hosted at CERN. The pilot is directly useful in providing prototypes, proof of concept, and demonstrations. 

Most of this leaflet is inspired by AARC2 SA1 Pilot Intake Template

[Copy&Paste from SA4T1 - Leaflet template]

Pilot Description

Main objective of this section is to provide a briefly high-level description of related pilot. The idea is to provide basic information, so that the reader can easily understand it.

Pilot goals

Some questions to answer:

  • What are the goals of this pilot?

  • Why is it in AARC project?

  • How this pilot will improve AARC community?

  • Why should I use this pilot instead of other solutions?

Description

Main objective of this section is to report detailed informations about pilot. 

Some questions:

  • How this pilot works

  • Reason to prefer this pilot instead of other existing tool

  • Detailed Scope

  • others

Components

This section will contain a lists of components used for this pilot.

It is not required to add a detailed description for each component, but 3 important parts are:

  1. Add Link to component web page
  2. Add a short description to explain its function (not more than 1 raw)
  3. Explain why these components have been chosen

An example:

  • Component A - Service provider
  • Component B - Bring order to chaos
  • Component C - Hide my precious treasure

Architecture

This section will provide 2 important parts:

  • Graphic representations of pilot architecture

  • Graphic representations of workflow

  • Lists of all components of related pilot

Use Cases

This section should explain how this pilot works through use cases (at least 2).

Use cases can be represented in the form of a table, where:
  • The title is the use case
  • Each line is a step
  • 2 columns available, first with text and description, second with a screenshot

(Here's a valid example LINK)

Further information

Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.