pre-GDB - Authz Working Group

Europe/Zurich
31/S-028 (CERN)

31/S-028

CERN

30
Show room on map
Description

Monthly meeting of the WLCG Grid Deployment Board See also Twiki GDB area for actions and summaries

Authorisation Working Group Twiki https://twiki.cern.ch/twiki/bin/view/LCG/WLCGAuthorizationWG#WG_Documents Contact e-group = project-lcg-authz

Meeting Purpose: Progress the work currently being done in the WLCG Authorisation Working Group to enable non-x509 Authorisation

Meeting Objectives:

  • Sign-off WLCG Authorisation Requirements Document
  • Sign-off JWT Usage Catalogue
  • Address comments in WLCG JWT Schema Document
  • Understand pilot progress and identify next steps
  • Begin discussions on operational impact

 

 

Registration
Participants

Pre-GDB Scribing Doc

17th July 2018

Attendees: Hannah Short, Linda Cornwall, David Crooks, Vincent Brillault, Romain Wartel, Ian Collier, Andrea Ceccanti, David Kelsey, Enrico Fasanelli, Mischa Sallé, Nicolas Liampotis, Mathieu Puel, Laurent Duflot, Mayank Sharma, Alessandro de Salvo, Jens Jensen, Oxana Smirnova, Brian Bockelman, Maarten Litmath  

Introduction

  • Comment from Dave, do we really want VOs to manage all the authorisation? By allowing groups and roles there is also scope for local policies.

  • There is little input from VOs, we need to make sure that there is consensus

    • Keep repeating message in GDBs

    • Discuss after holidays

    • Focus on what experiments need to do

    • Have per-experiment meetings with questions on a survey basis to fill in together

      • LHCb (Joel, Andrew)

      • CMS

      • ALICE

      • ATLAS (Alessandro)

  • Should leverage FIM4R definition of unique ID

  • Use case, national groups being given priority on infrastructures

  • Roles have always been groups in VOMS

  • We should be aware of the variety of workflows, local submissions, workflow managers etc

  • RBAC vs Capabilities is interesting, capabilities imply policy ONLY at the VO

  • Need caution with using capabilities for directory access, this model has been found to explode in reality (Globus)

  • Capabilities may make more sense for storage, groups may make more sense for processing jobs

  • Are we reinventing the wheel with our profiles? Should we be interacting more with EOSC Hub infrastructures?

    • There’s a REFEDS working group (OIDCre) defining a profile for research and education, trying to address mapping from SAML attributes to OIDC claims

    • AARC profile

  • How does it work with storage consuming different schemas? Shouldn’t be an issue but a common profile would help avoid mess

  • Identity profile - need to avoid confusion since this also includes groups, rename to “Attribute Schema”

  • The two profiles (Identity & Capability) are linked, you could request one from the other

  • Question from Enrico, where are the roles? Roles are removed but do have the concept of principle group and there’s a claims request to be able to select relevant groups (would need to be implemented in the WLCG AAI portal)

  • Question of using CERN SSO, certain experiments wouldn’t want to log in through CERN SSO. What about e.g. Belle II and COMPASS? This should be reusable, extensible etc, but customisable to LHC experiments where it makes sense.

    • Are there other CERN services that could need WLCG groups? E.g. Indico

    • If a user is suspended in CERN SSO they would not be able to access WLCG AAI, meaning only refresh tokens would work

  • Do we want CERN HR integration now or later? Maybe just to understand where it would fit in and how much work would be needed

  • Need to try and keep identity vetting link separate so that it can be decoupled.

 

IAM Pilot

  • NGINX VOMS plugin to allow IAM to understand VOMS proxy certificates

  • Focusing on generic attributes (key-value-pairs) & roles (groups with a flag) eta September

  • RCAuth deployed at CNAF. Need to understand whether CERN will want to deploy Master Portal & RCAuth stack, or whether there’s a shorter route for CAs at CERN (e.g. CERN’s IOTA CA)

  • RCAuth CA will be shortly deployed in a high availability setup, supported by EOSC-Hub, sustainability doesn’t seem to be a problem

  • IAM will basically implement a master portal

  • We need to consider rates and scalability, Mische says RCAuth high availability setup should be ok. Master portals can also be used for load balancing

  • Is there anyone from US who can comment? - from Brian, this is fine but similar to CiLogon. Comment that currently no OAuth2.0 flow.

  • Next step is to set up easy certificate provisioning

  • Could use the ssh flow to set up transparent local certificate provisioning, OR an OAuth client

  • Long lived, 11 day proxy stored in Master Portal

  • User can get a 12 hour proxy, derived from long lived proxy (can contain VOMS attributes)

 

EGI-Checkin/COmanage Pilot

  • Supports multiple authentication types, useful for non LHC experiments

  • Custom enrolment flows supported by COmanage

  • X509 & ssh support

  • Direct provisioning of VOMS

  • URN based group syntax

  • VOMS provisioning,

    • Challenge to associate RCAuth subject DN to user profile -> COmanage plugin & RCAuth integration

    • Challenge to query VOMS and add/remove users -> VOMS admin access from COManage Provisioning plugin (transparent?)

  • Missing HR DB (postponed) and active role selection

  • AARC recommends using Entitlements rather than Groups, using eduperson_entitlement. Should we be using this? It seems a bit unnecessary.

  • Would need a service that authorises the EGI Checkin VO

 

Requirements Doc

  • Do we want groups to be hierarchical? This should be made explicit

  • Capabilities can be derived from groups, or in different flows

  • Are we already including LoA in schemas?

  • What about provisioning? Seems out of scope of this WG

 

Key Decisions

  • Have interviews with each experiment to fully understand workflows and needs

  • Postpone pilot HR DB integration until after September, we may be able to get the information in another way

  • WLCG AAI implementation should be independent of CERN SSO or HR DB integration

    • For relevant VOs, grid groups (e.g. atlas-prod) should be maintained in WLCG AAI whereas high level groups (e.g. belongs to Atlas, is a CERN User) may be pulled in from e.g. CERN SSO

  • We recommend using the RCAuth.eu CA and software stack for certificates and token translation

  • Provisioning is out of scope of this Working Group. We should collaborate with e.g. DOMA

  • Give until early September for JWT Catalogue document to be completed

  • Publicise requirements at GDB, ask for Feedback

 

Actions

  • @Hannah create a doc to define the survey questions for experiments (survey defined by WG)

  • @Hannah rename Identity Schema to Attribute Schema in JWT Doc

  • @Andrea improve description of claims request flow, equivalent to role selection

  • @Hannah work out whether HR identity vetting and affiliation end date information is in SSO tokens (or can be in future)

  • @Hannah add requirement that changes should be backwards compatible and pilots done in the same way

  • @Hannah/WG Start discussion with AARC regarding simplified group syntax

  • @Hannah schedule call to compare schemas between us, AARC, REFEDS etc

  • @Nicolas/Andrea schedule a call to synchronise test VOs

  • JWT Catalogue (Deadline for September 1st)

    • @Miguel, JWT Catalogue, please respond to Mischa’s comments regarding key management (@Hannah, ping Miguel)

    • @Paul to follow up comments

    • @Catalogue authors to update their section and table rows in the document

    • @Hannah add summary text

  • Requirements Doc

    • @Hannah make shoulds -> musts where appropriate

  • JWT Schema

    • @WG add LoA aspects into JWT schema

    • @Hannah to schedule next call in September

 

GDB Presentation points

  • Background

  • Survey

  • Requirements signoff

  • Operations, how much should be run at CERN?

    • Numbers?

There are minutes attached to this event. Show them.