WLCG AuthZ Call

Thursday 27 Mar 2025, 16:00 → 17:00 Europe/Zurich

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
• 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

 

Zoom meeting:

Link below, in the videoconference section. Please ensure you are signed in to Indico to see the meeting password!

Next Meeting: 

• TBD

Present: Adrian (APEL), Angela, Berk, Dave D, Dave K, Dimitrios, Enrico, Federica, Hannah, John, Linda, Maarten (notes), Matt, Patrick (CERN IAM), Petr, Roberta, Stephan, Tom

Notes:

Maarten points out that APEL development for token support would be a good topic to discuss today, because of the presence of Adrian from the APEL team. The issue is that jobs submitted without VOMS proxies to HTCondor CEs, i.e. using just tokens, currently are not attributed to any VO by the APEL parser for HTCondor, which expects a job's VO to be determined from VOMS proxy details getting recorded in CE logs. The LHC experiments can continue equipping their pilot jobs with VOMS proxies for the time being, but a few other VOs have stopped or will stop doing that. Maarten shares the short document describing the current state of affairs w.r.t. determining the VO from various types of tokens that APEL would be confronted with. 

Several comments may need to be integrated into the main text. While a medium-term solution may come from the GUT Profile WG, we need a short-term work-around to allow VOs to stop sending VOMS proxies without hampering accounting. ARC CEs have their own accounting which faces similar issues. An alternative for the client side of APEL would be AUDITOR, which is being tried out at several sites and will be reported on in the WLCG Workshop in May.

Adrian points out that the APEL team would need help from a friendly HTCondor CE admin to discover together what would be the minimal changes to make APEL work as desired for token-only jobs, because RAL does not operate HTCondor CEs. Daniela Bauer from Imperial College might be able to help out and she will be contacted by the APEL team.

Stephan argues that no accounting SW should need to derive a job's VO from looking at details logged for its token. Instead, the CE should have a hook for accounting that is invoked at the time the CE decides to which account to map the job. Such a mechanism could work in a similar way both for HTCondor and ARC CEs. Petr replies that he had already proposed such a mechanism to the ARC developers, who decided to rely on the wlcg.groups claim for the time being, which does not work for Check-in tokens, nor for LHCb, as explained in the ticket. [ ALICE tokens would need to have it added. ] Update on March 28: comment 12 in that ticket now describes how ARC 7.0.0 also supports a mechanism like what was proposed by Petr.

Maarten will ping the HTCondor and ARC developers about these matters. He adds that we still need a short-term "hack" to bridge the gap between the current situation and the medium-term solution.

Stephan observes that jobs could actually provide accounting details in their JDL / xRSL attributes. Maarten concludes this would even give more reasons for the HTCondor and ARC developers to consider a common approach.

Next, Petr asks what the plans are for IAM upgrades? Berk replies he has been carefully testing release candidates, in particular because of extensive changes in the HR DB lifecycle code. He expects to do the upgrades in 3 weeks, when he will be back from an upcoming absence. For the record, Maarten adds that the last of the legacy instances on OpenShift have been switched off a few weeks ago, after having served us well for several years. He has updated the VOMS configuration details accordingly.

Finally, Petr asks when IAM will be able to distinguish user from service accounts? Enrico replies he just approved a PR adding a flag that will allow marking accounts that must not have an AUP signature requirement. It should be part of the 1.12 release foreseen in about 1 month. Petr then asks if the property could be exposed through the SCIM API? Enrico replies it should be easy to add and have also that feature in the next release. Maarten adds that the addition of that flag will be very welcome to several experiments that currently have to be concerned about service accounts getting blocked due to expiration of their AUP signature.