Login

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>

Hide

Participants: Andrea, Andrii, Brian, Dave D, Dave K, David C, Enrico, Federica, Ian C, Irwin, Jeny, Jim, Julie, Linda, Liz, Maarten, Marcelo, Mine, Petr, Tom, .....

Notes:

  • User sync
    • CMS: working OK
    • ATLAS: code development in progress, ETA ~end of this week
    • no further obstacles foreseen for other VOs

 

  • Use of the audience claim
    • specific case: what to do for DUNE EOS at CERN?
    • this was already summarized in our profile document
    • in a nutshell: SE audience == SE hostname / alias
      • the SE code needs to allow real hostnames and any relevant aliases
    • audience can thus be auto-derived by FTS for a token exchange operation
      • and similarly by other frameworks and tools
    • this is also discussed in our vCHEP paper "WLCG Token Usage and Discovery"
      • e-mail thread "vCHEP Submision Final Comments" (sic) has ~final draft as a PDF
    • audience claim is required
    • IAM clients need to request it using the current API ATM
    • at some point we may want to move to the proposed standard for that:
    • the end user does not have to know about such details (and generally had better not)
    • for stage-out, the token has to be restricted by the submit service before being given to a job
    • how that happens depends on the VO's job framework and use cases it needs to support
      • 1) pilots could be submitted with (coarsely or finely) restricted tokens
      • 2) pilots could obtain restricted tokens from a central service at run time
      • the frameworks of some VOs may need to support both approaches for different use cases
      • for example, HPC WNs may not have outbound connectivity
      • NorduGrid ARC CEs already deal with HPC restrictions since many years
      • ALICE use option 2 at the expense of continually high load on central services
      • each VO needs to decide on a sweet spot between various desirable features
    • HTCondor already has functionality to keep refreshing job tokens of limited lifetimes
    • HTCondor may need some development to support such use cases even better
    • htgettoken already supports restricting the audience
    • these matters will be discussed further in the CE hackathon, June 3-4 (TBA)
      • and possibly in the pre-GDB on Worker Nodes
    • note: ATM we are mostly concerned with submitting the pilots themselves
      • the user payloads can still use X509 proxies

 

  • User tools for dealing with tokens
    • in the GDB on Wed, Will presented how SSH resources can be accessed using IRIS IAM
    • there will likely be a set of tools for different use cases
      • htgettoken, oidc-agent, PAM modules, .....
    • those developments currently are represented in the AuthZ WG
    • we will keep presenting and discussing such tools as needed
    • we will try and aim for common ground where desirable

 

  • WLCG Token Transition Timeline document
    • we mainly started discussing the VOMS-Admin use cases detailed in chapter M.3
    • a VOMS-Admin API service could be added to IAM
      • estimated to take less than 1 week of development and testing
      • as it still is a non-trivial effort, it would need to be defended
      • we go through the list of use cases and see if a critical mass remains
    • IAM can serve mappings to EOS instances that need them (very few do)
    • we are not worried about the DPM clients of our VOMS-Admin services
      • no LHC experiment should depend on that functionality
      • if some instance were found with a peculiar configuration, it can be fixed ad-hoc
    • when VOMS-Admin has been stopped for a VO, it can still be resurrected for a while
      • it just would keep getting staler
      • critical DNs could still be added manually by VO admins
    • to be continued...

 

Actions:

  • none

 

There are minutes attached to this event. Show them.
The agenda of this meeting is empty
Powered by Indico v3.3.6-pre