WLCG AuthZ Call

Europe/Zurich
Description

Proposed agenda: 

Zoom meeting:

Please ensure you are signed up to project-lcg-authz@cern.ch to receive the meeting password!

Join Zoom Meeting
https://cern.zoom.us/j/94718857994

Meeting ID: 947 1885 7994
Password: <see email>
One tap mobile
+41432107042,,94718857994# Switzerland
+41432107108,,94718857994# Switzerland

Dial by your location
        +41 43 210 70 42 Switzerland
        +41 43 210 71 08 Switzerland
        +41 31 528 09 88 Switzerland
        +33 1 7037 9729 France
        +33 7 5678 4048 France
        +33 1 7037 2246 France
Meeting ID: 947 1885 7994
Find your local number: https://cern.zoom.us/u/abjrVtLBu4

Join by SIP
94718857994@188.184.85.92
94718857994@188.184.89.188

Join by H.323
188.184.85.92
188.184.89.188
Meeting ID: 947 1885 7994
Password: <see email>

Participants: DavidC, Maarten, DaveK, Andrei, Tom, DaveD, Romain, Enrico, Federica, Irwin, Jeny, Jim, Julie, Marcelo, Jeffrey, Sven, Fabrizio

Notes

  • Central suspension
    • This meeting is to set the scene for future meetings
    • EGI can centrally suspend a DN, some question over whether this happens in practice. Argus is not necessarily used.
    • Designed so that there were various policy points where policies could be evaluated and enforced. Wanted to allow others to apply policy as well as just certificate revocation. Was an EU focused architecture.
    • We should avoid making something that is too complex. Current system is over-engineered.
    • We do need to have the same, or similar, functionality.
    • Who should be involved in defining this?
      • Technical
      • Policy
    • How does this happen technically?
    • How does this overlap with threat intelligence sharing?
    • VO level suspension is effectively solved (this is what we have). However, we have no possibility at the site level when using native OIDC.
    • How can we deal with people overloading a site? Sites would want to be able to block activity from that user immediately. 
    • We have never had an incident where site level blocking was seen as critical, however we shouldn't assume this for the future
  • Capability sets
    • If a client requests a capability set and a scope that happen to be the same e.g. storage-read but for different paths, they should both be returned
    • Returning an error if not entitled
      • Plenty of error handling in the OIDC spec
      • Consider adding how the error response should look
      • https://tools.ietf.org/html/rfc6749#section-4.1.2 error response could be access_denied
      • We should make it consistent between group requests and capability set requests 
  • IAM needs to start issuing kerberos principal name

Actions

  • Hannah to send WLCG IAM DNs to Maarten to be included in RPMs
  • DavidC form subgroup to work on this topic
  • Hannah to look up how we deal with requesting groups that we're not entitled to 
  • Dave to edit capabilitiset 
    • Remove part about "different values"
    • Make groups and capabilityset request failure consistent 
  • Andrea and Hannah to start issuing kerberos principal claim, see with DaveD which claim name to use
There are minutes attached to this event. Show them.
    • 15:00 15:05
      Announcements etc 5m
    • 15:10 15:30
      Central Suspension 20m
      Speaker: Dr David Crooks (UKRI STFC)
    • 15:30 15:50
      Capability Sets 20m
      Speaker: Dave Dykstra (Fermi National Accelerator Lab. (US))