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.
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
(TBC, screenshots will be available in December)
User links x509 certificate with federated credentials
| Step | Screenshot (TBC) |
|---|---|
| User registers with the system using a federated account | |
| Admin approves registration | |
| User associates x509 user certificate with their account | |
| User is granted roles/groups | |
| User adds roles/groups to proxy certificate | |
User submits a physics job
| Step | Screenshot (TBC) |
|---|---|
| User registers with the system | |
| Admin approves registration | |
| User uploads SSH key | |
| User requests token from command line | |
| Token is provisioned transparently | |
| User submits a physics job |
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? how?
About sustainability:
- will this pilot survive after AARC?
- If yes, how?
- if no, why?