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:
There are minutes attached to this event.
Show them.
