WLCG AuthZ Call

Thursday 14 Mar 2024, 16:00 → 17:00 Europe/Zurich

Previous Actions:

• Action, Maarten: to collate the changes for the profile, with ones to be made now and ones to be considered further
• Action, all: review profile changes as required.

Proposed agenda:

• Token Profile: Open Issues and PRs
  
  • https://github.com/WLCG-AuthZ-WG/common-jwt-profile/issues
     
  • https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pulls

 

Zoom meeting:

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

Next Meeting: 

• 28 Mar 2024

Present: Brian B, Dave D, Dimitrios, Enrico, Federica, Francesco, John, Linda, Maarten (notes), Mine, Mischa, Petr, Roberta, Stephan

Notes:

Maarten informs the meeting of the existence of two transition timelines:

1. from VOMS-Admin to full dependence on IAM, to be done before the EOL of the VOMS-Admin support due to the EOL of CentOS 7 on June 30;
2. from IAM on OpenShift to IAM on Kubernetes (K8s), which we want to do for various technical reasons, but without a hard deadline.

These timelines used to be intertwined, but have recently been decoupled. The latest version of the timelines can be seen in this document that also explains why we want to move to K8s and why the new instances have to have new hostnames, which actually may be a good thing after all, as they allow the new services to be tested independently of production, yet already be recognized by services at sites. To that end, two campaigns have been launched this week:

1. VOMS-aware services should have the new LSC files added, as documented here;

2. token-aware services should have the new issuers added.

Brian asks if any subjects would change due to the migration to K8s? Maarten answers the OpenShift and K8s instances will share the DB that defines the VO members, groups, roles, clients, etc. Hence there should be no need to define new subjects etc. Such a setup has been tested by Berk using a few dev boxes, but the IAM devs did not express concerns about doing that with production instances. That said, we aim to have stress tests on a few dev instances to see if we can provoke any race condition. If there happens to be a concern after all, the good thing is that our production instances do not have to be stressed any time soon, because we can keep doing our data management with VOMS proxies for the time being. In DC24 we did stress our production instances, but that was on purpose for the Data Challenge, to see where our limitations currently are. Regarding deployment options on K8s, we had a meeting between CERN and CNAF K8s deployment experts to discuss the pros and cons of various choices and there are more such meetings to come still.

Next, Mischa expresses a concern that many VOs on EGI may even be unaware of the VOMS-Admin EOL and in any case they should be pushed to start planning on migrating out of it. Maarten thinks he remembers a broadcast about the matter, but not a ticket campaign to contact all the VOs. There should also be documentation on what VOs can do. He will follow up with EGI Ops (done). Francesco says he would like to be in the loop early on if IAM is going to be proposed as a viable solution for VOs (done). Mischa says that the PERUN attribute service might be an alternative, but that it may in turn rely on a VOMS and possibly even a VOMS-Admin service for the creation of proxies. Brian asks if IAM actually is a supported product in EGI? Maarten replies there is no support unit for IAM, but there are a few that come close. Maarten will follow up with EGI Ops on the creation of a proper SU (done). Petr reports there are 297 VOs listed in the EGI Operations Portal. Most of those probably need to do something.

Next, Maarten reports he did not yet find the time to merge all the easy PRs and close the corresponding issues for the WLCG profile, but the intention remains to release a new version, probably 2.0, of the profile this spring. The harder cases, e.g. a change in the behavior of the stage scope, will have to be discussed between all affected parties, in AuthZ WG and/or DOMA BDT meetings.

Next, Petr asks what the plans are for anonymous clients? Francesco answers that anonymous clients using the client-credentials flow will be blocked as of IAM v1.8.4, whereas oidc-agent will keep working, which it has to. He adds there will be a strategy to ensure that clients will (almost) always end up with a listed owner. Petr remarks the owner of a client can e.g. change the grant types. Francesco answers the plan is to reduce the flexibility offered in the GUI by the underlying MitreID engine. For example, it should not be possible to switch an existing client to another type. However, not too many changes will be made, because the plan is to move away from the MitreID engine to Spring Authorization Server. Petr asks if that implies a complete change of the OIDC back-end? Francesco confirms and adds that also the GUI needs to be moved away from AngularJS whose EOL was in 2021. Petr: a completely different stack? Francesco: IAM will still be a Spring Boot application. We will have to make some adjustments to components we use, e.g. to stop storing access tokens in the DB. Petr: will scope and token exchange policies remain the same? Francesco: the current policy engine is not so usable / scalable. Open Policy Agent looks promising, also for EGI Check-in. We want to do that work as part of a new EU project that was submitted 2 days ago: if it gets approved, it would start in 1 year and hopefully run for 3 years.

Next, Maarten points out we need to come up with a shortlist of high-priority issues we need to get fixed before the experiments can start relying on IAM for VO management. For example, AUP expiration reminders currently are not sent. He adds there also is requirement for VO admin training and that he intends to record a video with a demo of typical VO admin tasks.

Next, Stephan asks what are the handles on refresh tokens (RT) that can be configured today? Automatic rotation after use? After a certain time? Other options? He adds that CMS want to start implementing various workflows that depend on RT behavior. Francesco: a client can ask for a new RT each time it gets an access token (AT), or do that only when the remaining RT lifetime has fallen below some threshold. Enrico adds the default behavior is for the current RT to be kept. Dave points out it is not good practice to wait until the remaining lifetime has become rather low, because an RT might then expire due to unavailability of the issuer. Instead, he advises RTs to be renewed much more frequently, e.g. daily. Maarten underlines such a rolling approach. Francesco adds a grace period could be permitted for an RT that has just expired. Dave replies CILogon has implemented that concept. Maarten concludes an IAM issue may need to be opened about making these things more convenient for clients.