WLCG AuthZ Call

Europe/Zurich
Description

Proposed agenda:

  1. Specific discussion on implementation of scopes (how they align with e.g. api endpoints) 
  2. Schema document comments https://docs.google.com/document/d/1cNm4nBl9ELhExwLxswpxLLNTuz8pT38-b_DewEyEWug/edit?usp=sharing 
  3. Preparation for September pre-GDB https://indico.cern.ch/event/739896/
Videoconference Rooms
WLCG_AuthZ_Meeting
Name
WLCG_AuthZ_Meeting
Description
WLCG_AuthZ_Meeting
Extension
10669715
Owner
Hannah Short
Auto-join URL
Useful links
Phone numbers

Attendees: Linda, Hannah, Dave, David, Maarten, Romain, Mischa, Tom

Notes: 

  • Scopes in StoRM & IAM
    • Q from Andrea. What are we missing? Some concrete use cases. Bit confused about which capabilities are needed for actions. 
    • SCIM example, using a decorator to require read/write scopes for operation in addition to general token verification
      • Doesn't go into path level granularity but considering for the StoRM use case
    • Example from Webdav
      • Need to define based on logic for path permissions based on the work of this group
    • Depends on the set up. We should try to have a consistent approach.
    • Transitivity is very useful in terms of implementation, and avoids having to list a large number of paths (leading to token bloat) 
    • We need to allow VOs to define which permissions are freely given, and which are not. This is to avoid giving "/" permissions to users and granting access to others' home directories (for example)
    • Scope for traversing a path? In POSIX you do need to have search permissions on leading directories to traverse. It makes life more complicated. However, may be required for privacy/security reasons.
    • Also metadata scope? Not currently used in SciTokens. Assume that usual read permission also allows metadata read
    • Proposal: ignore both traversing and metadata scope until a point where we have a use case.
    • Overwriting during put/copy/move? Typically want to have some indication of whether an overwrite is forced, possibly at a protocol level rather than scopes. Maybe this logic needs to come from VO. 
      • Current schema doc says storage.create does not allow overwrite 
      • Requires more thought
  • Document
    • Multiple anonymised subjects? Does this mean pairwise subject? Concern from Matt Crawford about blocking
      • Where has this come from? Believe it's a non-issue
      • General agreement that an Opaque ID ok but does not protect against profile building etc. Privacy people were not very happy about this back in the day.
    • Maybe we got lost about the default groups again...
    • Do we need a bigger discussion on the generation of opaque IDs (how, where mapping is stored, how resolved, and by who)? 
    • Do we need to add the concept of primary group into the spec?
  • September pre-GDB: https://indico.cern.ch/event/739896/
  • Mini FIM4R: https://indico.cern.ch/event/834658/

Actions:

  • @Hannah start email thread about scopes required for overwriting a file
  • @Hannah add opaque IDs to pre-GDB parking lot
  • @Hannah add a pre-reading list to the pre-GDB
  • @All read through the doc
There are minutes attached to this event. Show them.
    • 15:30 15:50
      Scopes in IAM and StoRM 20m
      Speaker: Andrea Ceccanti (Unknown)