WLCG AuthZ Call

Thursday 12 Jun 2025, 16:00 → 17:00 Europe/Zurich

513/R-068 (CERN)

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), Angela, Dave D, Dimitrios, Enrico, Federica, Hannah, Linda, Maarten (notes), Matt, Mia, Patrick, Petr, Roberta, Stephan

Notes:

Maarten informs the meeting of progress made with the APEL accounting for jobs submitted without VOMS proxies, for which VO information thus has to be obtained from the token that was used instead. Petr submitted a PR for the htcondor-ce-apel package already 3 weeks ago.

While the code was tested OK, Maarten noted that some constructs in the patch could still be improved. Max Kühn from KIT then proposed replacements for them, noting that yet further improvements could be envisaged. The HTCondor team had no time yet to consider the PR. Petr will look into adjusting the PR with the proposed changes. Adrian suggests that Simon Fayer might again be willing to test the new code at Imperial. Maarten has looked into what might need to be done for the case that Slurm is used behind an HTCondor CE, as is the case at a few of our sites. The admins of one such site, HEPHY Vienna, provided the list of relevant rpms they use with their setup. From that list and from looking into the code, Maarten is under the impression that Petr's changes may also be sufficient for that use case, but Petr warns that some information is obtained from the HTCondor batch system instead of the CE. Maarten will have another look, but thinks that not much work should be needed in any case.

Next, Petr starts a discussion about an inconvenience with storage scopes that particular clients should be restricted to. In particular, Petr would like refresh tokens (RT) to be configured without path restrictions, i.e. with "/" as the path, while any obtained access tokens (AT) will in any case be restricted by the applicable policies, if any, defined for the given client. One use case would be for VO experts to be allowed to use the test areas on all SEs, which unfortunately are located under many different paths. Enumerating them all in the RT and/or AT could take up to 14 kB, which is way too much and also bigger than the 2 kB allowed by IAM for scopes. Making the namespaces more uniform could reduce the size to 4 kB, but even that is too much.

Federica replies that this problem only occurs for clients created with oidc-agent, not for clients created in the IAM dashboard. She adds that the current behavior is the result of a refactoring of the handling of scopes, making the device code flow behave more like the authorization code flow, and that it is in fact a Spring requirement: the set of allowed scopes needs to be filtered at the time the consent is given to the client. The trouble then comes from the oidc-agent client being anonymous. The desired behavior can be obtained by registering the client directly in the IAM dashboard and doing a device code flow e.g. with curl. Enrico adds that today, consent needs to be given to the exact set of scopes presented at that stage, that their cannot be some implicit reliance on a policy being applied later.

Petr asks if this might be considered a flaw in our profile? Maarten suggests an issue be opened to discuss this matter further and allow us to have a handy reference to any decisions taken about it. Petr suggests SE home directories for users might be another relevant use case, requiring a policy per user. Stephan replies CMS is relying on patterns for that use case and he is interested in learning if there could be a problem with that: perhaps it was only allowed by older IAM code.

Maarten asks what would be the workaround for the first use case? Petr answers there are no policies for Rucio and there are no policies needed for users yet. Maarten adds this matter reminds us of the blocking issue reported by LHCb, which also comes from the non-uniform namespace across SEs: beyond the site-specific VO root directory, also within the LHCb namespace there is non-uniformity across the sites. Symlinks were proposed as a workaround, but LHCb replied there would be many needed. Petr adds he would need to check how dCache checks permissions when symlinks are involved. Furthermore, some ATLAS T1 sites have a co-located T2 using the same SE with a differently organized namespace!

Petr thinks he remembers manual device or authorization code flow tests failing similarly, but he will check again. He asks if anyone else is using parametric scopes? Enrico replies he has never seen those outside of WLCG. Maarten adds that WLCG looks a pioneer also in that respect and that other communities will follow our examples once we have got things to work for us.

Next, Enrico provides us with some news regarding IAM releases. 1.11.2 is a bugfix release that can just be deployed on top of 1.11.1, whereas 1.12 requires DB migrations. It brings many improvements, including the reader role and the flag to exempt service accounts from signing the AUP.

1.13 will have these improvements:
* the tail of changes that did not make 1.12;
* contributions by Patrick and Mia from the CERN IAM team;
* the client secrets will be hashed;
* access tokens will no longer be stored in the DB.

Once that release has been delivered, the CNAF team will need to work on OpenID Federation support, which might be of interest to WLCG in the longer term, but is already needed by other communities.

Finally, Maarten soon expects to have some quiet time to work on adjusting and merging the open PRs for our profile and adding some text to make clear that the table with token lifetimes indicates what we would like to do as much as feasible, but that we already know various use cases where we will need much longer lifetimes, for which some examples will be added as well. The WG will be informed when a first v2.0 draft is ready for being reviewed.

Our next meeting is planned for June 26.