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:
| Component | Description | Why did we choose it? | Link |
|---|---|---|---|
| RCAuth | Token Translation. Used to generate x509 certificates for access to legacy services | EU wide, sustainable infrastructure component | https://rcauth.eu |
| VOMS | Attribute Authority & Membership Management. Legacy authorisation database for WLCG, must be integrated for backwards compatibility | Pre-existing. Backwards compatibility | https://italiangrid.github.io/voms/ |
| CERN HR DB | Attribute Authority. CERN's source of identity vetting information | Pre-existing. Backwards compatibility | N/A |
| INDIGO-IAM | One option for the proxy and membership management component | Implements multiple components, easier maintenance. Product used by other communities. | https://www.indigo-datacloud.eu/identity-and-access-management |
| EGI-Check-in | The second option for the proxy and membership management component | Implements 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:
AARC BPA version:
Use Cases
Videos for the AARC supported pilot for EGI-Check-in are available at link
User links x509 certificate with federated credentials
| Step | Screenshots |
|---|---|
| User registers with the system using a federated account |
 |
| User associates x509 user certificate with their account |
|
User submits a physics job
| Step | Screenshot (TBC) |
|---|---|
| User follows registration flow above | |
| User requests token from command line (Device Code Flow) |
|
| 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:
- Add Link to component web page
- Add a short description to explain its function (not more than 1 raw)
- 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).
- 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.