Attendees:
(Vidyo) Adrian Coveney, Brian Bockelman, David Groep, Linda Cornwell, Mischa Sallé, Paul Millar, Riku Silvola, Susan Sons, Tommaso Boccali, Greg Corbett, Antonio Falabella, Maria Arsuaga-Rios, Peter Gronbech
(In the room) Romain, Simone, Andrea, Marcus, Michel, Miguel, Joel, Liviu, David, Vincent, Stefano, Julia, Paul, Ulf, Ian C, Claudio, Nicolas, Dave, Maarten, Catherine, Hannah
Previous meetings:
Summary:
- World is moving to OAuth2 and JWT, we should go with them - let's not invent our own solution
- Although Certificates have been a simple and functional solution, there are now more user friendly alternatives that we can employ to the benefit of our researchers
- Topics can be split into requirements for VO Membership Management and for Services
- Draft Requirements Document available for comment
Main points from morning discussions:
- Authentication and Authorisation can be decoupled to a certain extent
- VOs require different attributes on a user than downstream services
- Best approach is to focus on a solution for the 95% of our users and assume that some power users will still manage certificates in the years to come
- Certificates have been a very elegant solution and, if any community can manage them it's ours (!)
- However, generally accepted that certificates are unworkable for early career researchers and, now that we have other options, they should be explored
- Some services, e.g. CRIC, have had to define their own solutions to share authorisation attributes between web and non-web services
- Services should receive ID & groups/roles/capabilities from VOs and be able to get additional information on users simply
- We should follow standard approaches for authorisation, current progress points to bearer tokens JWT/OAuth2
- Assurance of membership process should be maintained for LHC VOs, i.e. link with CERN HR db, when users are able to register via non-x509 credentials
- Suspension necessary at token level/VO user level/VO level/Site level
- User's identity is within context of VO and not global (although can be bootstrapped)
- We recognize there is an important distinction between the "LHC VOs" and the "WLCG VOs".
- Aim to have an infrastructure where a generic WLCG VOs can bring their own identity management.
- The *implementation* for the LHC VOs should leverage CERN SSO and maintain CERN's identity vetting process.
- The distributed infrastructure should see a common authorization approach at the inter-VO level, regardless of the identity management used.
- Users should be able to give their consent for authorisation and provide constrained delegation to services
Main points from afternoon session:
- Must ensure interoperability between EGI and OSG - work required to define a standard for authorisation tokens
- WG should define clear requirements for VO Membership Management tool and share with solution providers to determine best approach (mustn't forget transition period from VOMS)
- INDIGO IAM is likely next evolution of VOMS but there are multiple possibilities
- A token translation service is required and should be centrally run to aid integration with services
ACTIONS:
- Hannah to circulate requirements document for further input and plan Vidyo meeting for week of December 11th
- Hannah to share WLCG FIM4R input with group
- Andrea and Nicolas to demo full JWT workflow (including VO registration) at next meeting
- WG to define requirements for VO Membership Management Tool and assess solutions (such as INDIGO IAM or CoManage) against them
- In collaboration with AARC
- Jointly (EGI/OSG/WLCG) define a joint profile for OAuth2
- content of the access token
- OAuth2 proof of concept of interoperability between OSG and EGI
- retrieving a token/sending the token (could also be done in VO?)
- Provide command line solution to allow users to submit jobs without certificate management (AARC Pilot with Mischa, transparently provision proxies using ssh)
- WG to consider Token Translation services