WLCG AuthZ Call

Thursday 27 Jun 2024, 16:00 → 17:00 Europe/Zurich

Previous Actions:

Proposed agenda:

• Recap of IAM hackathon

• High-priority IAM issues working document

  • Please check it out and comment where needed

 

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

• 11 July 2024

Present: Dimitrios, Enrico, Federica, Maarten, Matt, Panos, Petr, Roberta, Stephan

 

Notes:

 

Stephan reports he would like to know what the thinking is about refresh token (RT) renewal / rotation, as CMS workflows are being designed assuming the currently allowed behaviors. For example, if a 30-day RT is renewed after 3 weeks, the new RT has again a 30-day lifetime, whereas some people may prefer the end date of the new RT to be the same as that of the original RT, to prevent a stolen RT from potentially being renewed indefinitely. Francesco had looked into what standard documents say about this, but it is a grey area. Maarten points out that even if a standard forbids what is currently allowed by IAM, we may decide we need it anyway: those standards were not written by anyone running a grid. We have robot workflows that need to run without requiring human interaction every N days or weeks. Enrico points out that if a stolen RT were renewed by an attacker, it can no longer be renewed by the owner, who would thus see an error and could revoke the stolen token and its descendants. Petr points out that people may just assume something went wrong and cure the problem e.g. by creating a new client. Stephan suggests that privileged clients could be allowed more freedom regarding RT behavior than normal clients. Maarten summarizes that we need a way to allow central services to be run autonomously, either using RTs having an infinite lifetime or with RTs being infinitely renewable. He adds that the latter option would be somewhat safer, because a stolen token would then become unusable if it has not been refreshed fast enough. It would then seem better to reduce the RT lifetime to 1 day or so. Petr points out there is a way to avoid RTs altogether: ATLAS are using client-credential clients that can just obtain new access tokens when they need to. He adds that such clients have some limitations, though. For example, IAM currently does not support defining path restrictions for them. Enrico replies the policy engine is currently focused on users and groups, but could be enhanced to support client IDs and even audiences.

 

Stephan will open a new issue describing the CMS use cases. Done after the meeting: 799.

 

Enrico points out non-trivial code changes will be needed in various places to implement the desired distinction between privileged and normal clients, configurability etc. This matter therefore is not for July.

 

Next, Federica asks Petr to comment on issue 524, "Unable to login with CERN secondary account". It is agreed that the cern_person_id attribute should be checked only on registration, and not on logging into an account that already exists. This change will allow people to log into IAM via SSO with a secondary account, connected to an IAM account created through the API.

 

Next, Maarten reports that for almost all VOs, the legacy VOMS and VOMS-Admin services have been switched off. ATLAS were the first at the beginning of June, followed by ALICE 2 weeks later, then LHCb on Monday and CMS this Thursday afternoon CEST. Of the small VOs only OPS is left, used by the EGI Availability and Reliability monitoring system. After the meeting the green light was received also for that VO and acted upon Friday morning.

 

Maarten adds that the IAM services at CERN have been upgraded twice since our previous meeting: first on June 13 to a 1.9.0 pre-release that fixed several high-priority issues, then on June 25 to the final 1.9.0 release that brings a few more enhancements, in particular a fix for an important issue of interest to ATLAS and LHCb, viz. the automatic provision of a new user's nickname upon registration. He notes that a 1.9.1 release is planned for July with further fixes of high-priority issues. Enrico confirms there are several fixes already on review, for example concerning: missing notifications; adding X509 DNs to user records; default groups for new users. Details here. He points out that several fixes were provided by new contributors at STFC and CNAF! Maarten concurs it is great to see new names being thanked in the 1.9.0 release notes indeed.

 

Next, Petr points out ATLAS are very keen on allowing experts to see the relevant details of all users, viz. their groups, nicknames and X509 DNs, to help them troubleshoot operational problems experienced by users etc. Maarten replies he fully agrees with this request, for which he opened issue 794. Enrico replies the matter had been discussed before, but ran into privacy concerns at the time. Maarten will discuss this with Hannah when she is back.

 

Finally, Petr asks if IAM's managed-proxy functionality is considered good for production use, viz. for implementing the use cases currently handled by the MyProxy service? Enrico replies he has no experience with that functionality, but there is no plan to remove it. Maarten cautions there are various MyProxy use cases that might not all be supported by IAM. He adds we currently do not have big concerns about Globus or MyProxy, both of which are still supported, though nobody has officially committed to that support. Petr concludes he will look further into what IAM can do there.

 

The next meeting is planned for July 11, which happens to be bad timing for Maarten, because of the overlapping Operations Coordination meeting scheduled for that day, unfortunately.