WLCG AuthZ Call

Thursday 14 Aug 2025, 16:00 → 17:00 Europe/Zurich

513/R-068 (CERN)

Notes:

Apologies from Tom this week - I will be on leave, and so am noting this here ahead of time.

Previous Actions:

• Action: Maarten to tidy up and review open issues and pull requests for the token profile, and then circulate a potential 2.0 draft
  • Has made very good progress!
• Action: Maarten to look at reviving the RTE Task Force

Proposed agenda:

• Hackathon Recap
• Profile updates & Pull requests
• Token Accounting Cont - as needed

 

Open PRs:

• https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/57
  • storage.read and storage.stage descriptions
  • has had non-trivial updates - please check!
    
    
• https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/60
  • token lifetime guidance revision
  • has been adjusted and looks ready for merging
    
    
• https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/88
  • proposal to address issues 28, 29 and 39

 

A few more, hopefully easy PRs are still expected!

Zoom meeting:

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

Next Meeting: 

• Aug 21?
• Aug 28?

Present: Berk, Dave D, Donald, Maarten (notes), Matt, Mia, Michael, Patrick, Petr, Stephan

Apologies: Tom, John, Hannah, and many others

Notes:

Maarten proposes we have a proper summary of the very successful IAM community workshop and technical hackathon next time when the CNAF IAM devs can also be present. Berk summarizes several hackathon activities directly relevant to WLCG:

• Mia has added functionality to allow the 'nbf' claim to be slightly backdated as a protection against minor clock skews.
• She has also implemented a proposal from Mihai to have upscoping disallowed by default in token exchange workflows as used by the FTS.
• The SSO login bug that appeared with v1.12 has been fixed by Roberta. It required users to go through the whole SSO login procedure every time any IAM page was loaded in the browser.

Berk has done performance tests on a specially prepared IAM image that does not store access tokens in the DB. He found a performance increase of 5-10%, allowing access tokens to be obtained at ~1 kHz. We will have to see if that performance is going to be sufficient, but in any case it will be good to no longer store the access tokens, as there exist some concerns about pushing the ATLAS DB much further than the 21 M concurrent tokens it is handling today. Berk has asked ATLAS not to increase the transfer fraction handled with tokens until IAM has been upgraded to v1.13, which should have the desired feature.

Next, Maarten switches to the various open PRs listed on the agenda. PR #60 can still be commented on, but has already had significant discussion in our July 24 meeting as well as within the PR afterwards, and has been updated accordingly. Maarten intends to merge it next week.

Next, PR #57 has also had significant discussion within the PR and has also been updated accordingly. As we have not yet converged on some aspects of the storage.stage scope, the best we can do today is to indicate which operations need to be considered and where things look likely to be going. Maarten then draws attention to directory listings, about which v1.0 of the profile says nothing: the easiest would be to allow storage.read to be used also for that operation, but it has to be noted that the listing of (very) big directories has been notorious for causing significant resource consumption also on the server side, which could be an argument for a separate, possibly more privileged scope to prevent easy misuse.

Dave suggests that clever use of wildcards might be considered. Maarten replies the profile currently says nothing about wildcards and rather suggests all paths are to be taken literally; we would need to discuss such functionality with all data management experts. Stephan points out we currently do not have a way to protect servers against listing big directories using X509, and therefore, this matter does not need to be particularly considered now. Maarten will adjust the text to indicate that storage.read is likely to be deemed good also for listing directories.

Michael essentially is satisfied with the proposed changes being an improvement over v1.0, with future versions expected to finalize what cannot be decided yet at this time. Stephan adds that HL-LHC conditions may come with new requirements, for example to allow high-priority staging queues to be used by some of the people in an experiment.

Next, Maarten quickly goes through PR #88 which proposes a few changes to describe current practice better, including current limitations of the profile.

Next, Dave draws attention to issue #75 which was opened by Jim Basney after CILogon was seriously affected by high-rate token verifications from large numbers of concurrent jobs. Maarten suggests Dave and colleagues can just post a practical proposal in the PR, taking some inspiration from the WLCG Bearer Token Discovery standard, which we may want to refer to in an appendix about related documents. If we manage to converge within the next weeks, we can add another reference there already.

Next, Dave draws attention to PR #89 about the handling of different major and minor versions of our profile. Maarten uses the occasion to discuss if the next version really needs to be 2.0 or that we could settle for 1.1 instead, as none of the changes proposed so far breaks anything we have in production today? He argues that v1.0 should have spelled out certain aspects that we took for granted and that we are "only" correcting the document now. Petr points out that not only dCache, but also the SciTokens library has v1.0 hardcoded and that it would take a long time before we can use anything other than v1.0 in production. He suggests we can stick with v1.0 in production even when our document goes to v1.1. Maarten adds that a future v2.0 should rather signal that a backward-incompatible change needed to be made. The SW that currently hardcodes v1.0 needs to be adjusted according to this PR, though. Dave will update the PR changes following this discussion (done).

Finally, Maarten quickly shows the long list of PRs that have already been merged without any discussion, because they should not be controversial (e.g. cosmetic improvements), and describes how it has been tricky to convert the profile from MarkDown (MD) to PDF, via HTML, but that a workable solution was found. He has also prepared a big reformatting of the MD to be done after the currently open PRs have been merged: limiting lines to reasonable lengths as much as feasible, to make future "diffs" a lot less verbose!

Our next meeting is planned for Aug 28.