WLCG AuthZ Call
Previous Actions:
- Action: Tom to send an email to request topics and issues for discussion, and then we can plan a schedule of meetings upcoming
- Done - initial plan to focus on Accounting & Tokens
- Will ping for further requests
- Action: Maarten to tidy up and review open issues and pull requests for the token profile, and then circulate a potential 2.0 draft
- Action: Maarten to look at reviving the RTE Task Force
Proposed agenda:
- Token Accounting Cont.
Zoom meeting:
Link below, in the videoconference section. Please ensure you are signed in to Indico to see the meeting password!
Next Meeting:
- TBC
Present: Adrian (APEL), Andrew (NIKHEF), Berk, Dave D, Enrico, Francesco, Maarten (notes), Maiken (ARC), Matt, Mia (CERN IAM), Patrick (CERN IAM), Petr, Roberta, Stephan
Apologies: Hannah, Mischa, Tom
Notes:
This meeting has good participation for discussing accounting matters further. Summarizing some discussion on the mailing list, Maarten points out that for jobs submitted without VOMS proxies, we only have an issue with the HTCondor CE, given that ARC has its own internal accounting and sends complete job records to APEL. Petr replies that for the HTCondor CE, a small patch would be sufficient to allow the VO of each job to be obtained from the wlcg.groups claim in the token used to submit the job. The code currently relies on the presence of x509UserProxyFirstFQAN in the history record of each job. Instead, a flexible expression can be constructed that would also work when only a token was provided in the job submission, taking the VO from wlcg.groups in that case. Maarten points out that so far, we have not attached any crucial functionality to the presence of the wlcg.groups claim in tokens and that this use case would thus be a first. He adds that the use of that claim has been discussed many times in the past 2 years and that one use case would be the provision of context, for example for accounting, but at least ALICE currently does not set it in tokens used to submit jobs. Stephan adds that CMS has some ideas for the use of wlcg.groups in tokens, but that accounting was not on that list. He points out that the wlcg.groups namespace is not by construction protected against clashes between VOs. Petr replies the same is true for VOMS, which is resolved by policy. Stephan agrees that policies work in LHC experiments, but there may come other VOs using 3- to 5-letter acronyms for their own purposes that could then clash with ours. Maarten adds that such discussions already started 20 years ago and the solution at the time was to force new VOs to have DNS-like names. We might need to consider similar ideas at some point. He then points out that the other approach implemented by ARC would avoid all that, viz. the connection from token properties straight to the accounting in the configuration of the CE for a given VO. Maiken describes how it works and points to the documentation available through the ARC v7 release notes. Petr thinks that an HTCondor CE could have such connections implemented as an extension of the token mapfile, for which he provides an example.
A short discussion then follows about the amount of detail that needs to be provided in accounting records. Adrian clarifies that in practice, only VO-level accounting is relevant these days and that user-level accounting is even being considered for being removed altogether. Stephan points out that some OSG VOs are implemented as sub-VOs of an umbrella VO and for those, the issuer hostname is not sufficient: the subject needs to be taken into account as well. The consensus is that issuer + subject are fine both for HTCondor and ARC. Maiken adds that ARC supports each VO having several auth groups, e.g. one for production, etc. Stephan suggests HTCondor quota groups could be used to imitate what is supported in ARC. Petr replies it may be best to rely on the classad authentication attributes already recorded by HTCondor.
There is further discussion about what to do with wlcg.groups. Petr points out we can decide on that claim to be used for something in compute tokens, without having to be concerned about its possible uses e.g. in tokens for data operations. Stephan replies that it seems conceivable that some HPC facility might need to stage some image using the same token that was used to submit the job, and that we therefore had better allow compute and storage scopes to be mixed. Maarten adds we still need to determine how an ARC CE will be able to stage data in and out. Petr and Maiken reply that separate data management tokens would be delegated to the ARC CE, but that the details need to be worked out still.
Maarten concludes we seem to be closer to solving the token accounting issue than we thought before this meeting. Petr proposes to draft a message for the HTCondor developers and send it first to Adrian and Maarten for comments (done).
Next, Berk reports all IAM instances at CERN will be upgraded to the 1.11.0 release next week, after a lot of careful testing, in particular of the revamped HR DB lifecycle code that governs which users are deemed active in an LHC experiment and therefore should have their accounts enabled, and vice versa. Also the logging by that code has improved a lot.
Next, Dave reports some news from FNAL. First, Vault is being replaced by OpenBao, the free open-source fork of Vault. Second, in about a week, no more user proxies will be used by the Fermilab VOs, because of CILogon retiring its certificate services, while InCommon only supports IGTF server certificates. Maarten adds this affects the DUNE VO, who launched a GGUS ticket campaign earlier this year to ensure all their SEs would have support for DUNE tokens enabled on time. Dave adds that some tests were done to see if things looked sufficiently ready for the big change, but that the Rucio client configuration for DUNE was only fixed yesterday. However, it creates tokens valid for only 3 hours, instead of implementing the WLCG Bearer Token Discovery specification! To be followed up with the Rucio devs. Maarten concludes DUNE is the first of our VOs to venture into the new territory without VOMS and that it will serve as an example for other VOs!
Finally, our next meeting will likely be on May 22, since May 8 is taken by the WLCG Workshop.