WLCG AuthZ Call

Thursday Jul 25, 2024, 4:00 PM → 5:00 PM Europe/Zurich

Previous Actions:

• All to send high priority issues to the mailing list -> Enrico to create board for 1.11 release including those issues (not experiment specific but specifying initial requestor)
• Next call to focus on JWT Common Profile improvements for v 2.0
• Maarten to send email to working groups to ask for consensus on v 2.0 profile (allows developers to progress) 

Proposed agenda:

• Token profile PRs and open issues

 

Zoom meeting:

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

Next Meeting: 

• 8 August 2024

Present: Berk, Dave D, Davide, Dimitrios, Enrico, Federica, Francesco, Julie, Linda, Liz, Maarten (notes), Matt, Petr, Stefano, Stephan

Apologies: Hannah, Tom, John

Notes:

First the status and plans for the next IAM release are discussed. Enrico thinks a first release candidate could be provided on Friday, to be tested at CNAF and CERN in the next days, while the official release is planned to happen before the end of July. Among the issues fixed are the ones concerning e-mail notifications and the notion of default groups for new accounts. There also is the fix for a security issue. The new release will be 1.10.0 to signal new functionality compared to the current 1.9.0 release. Maarten asks if there is a schema change and suggests that any improvement that needs such a change might be postponed, to allow the services to be rolled back easily, should that be needed. Enrico and Francesco point out that the fix for the e-mail notifications has added a new table and that in general, for any new functionality, a new table is introduced, instead of modifying existing tables, exactly to facilitate rollbacks. Furthermore, Enrico will be around to provide support, should the CERN instances run into some trouble due to the new release. Moreover, the changes for 1.10.0 are deemed much simpler than the ones for 1.9.0, which has been working fine.

Next, Petr asks what are the CERN plans w.r.t. allowing secondary accounts to log in via SSO, which should only be a configuration change? Maarten replies we can followup offline, now that Berk is back again.

Petr then asks whether there has been progress in understanding how the HR DB API works regarding the start and end dates of contracts, which regularly causes users to be suspended. Berk replies he has been looking into the code for other reasons, viz. security fixes, but notes that the API only returns dates, not times, and that the observed issues would rather be on the IAM side. Petr concludes the fix might be as easy as letting IAM assume the end date is inclusive up to 00:00 the next day, and that the start date commences at 00:00 of the given date. He has updated IAM issue #805 accordingly.

Next, Petr starts a discussion about sustainable management of scopes. ATM, we only have the storage and compute scopes officially documented, plus the ad-hoc addition of the "fts" scope requested by the FTS team. In ATLAS, workflow management system developers were advised to make use of groups for the time being, while scopes would be a better fit. The standardization envisaged by AARC is more flexible about introducing new scopes, subject to namespaces that we currently do not have at all. Services like PanDA and Rucio might need their own scopes.

Dimitrios replies that Rucio just needs the user to present an ID token and Rucio will then determine what permissions each user has. Francesco points out that this looks very much like the way X509 is being used today and wasn't the idea we should move away from that? He suggests the rights of users could instead be stored in IAM.

Stephan notes that CMS is in favor of allowing additional scopes to be defined in namespaces and that CMS scopes would then have a CMS prefix. Francesco agrees that IAM needs to support the notion of namespaces per experiment and possibly even per user, adding that currently only the "iam" prefix is reserved. Stephan replies that CMS does not need custom namespaces per user, but that clashes between VOs will have to be avoided. Petr adds that only for shared services like the FTS the scopes need to be agreed between multiple parties.

Maarten concludes we will need to open an issue about this matter and continue the discussion there. He also notes that we can make use of policies agreed at the WLCG level, to avoid clashes that are not preventable by the configuration of the various IAM instances.

Stephan posits the owners of an IAM instance also own its scopes and that the WLCG profile needs to describe the common use cases. Francesco adds that VO admins should be able to configure policies to decide who inside their VO can get new scopes.