WLCG AuthZ Call

Europe/Zurich
Description

Previous Actions:

  • Action, Maarten: Start a VO information in token (for accounting purposes) discussion on the Mailing list late August to revisit and converge on a plan once summer holidays are more likely to be over
    • No need to follow up yet - just for tracking
  • Action, Mischa: Mischa to look to setup a "neutral" mailing list to facilitate cross-community discussions around unified token profile
    • Completed - email inviting WLCG AuthZ to register has been sent


Proposed agenda:

 

Zoom meeting:

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

Next Meeting: 

  • TBC
Videoconference
WLCG AuthZ Call
Zoom Meeting ID
61554826915
Description
Zoom room for WLCG AuthZ Call
Host
Tom Dack
Alternative hosts
Maarten Litmaath, Hannah Short
Useful links
Join via phone
Zoom URL

Present: Tom D (Notes), Stephan L, Maarten L, Francesco G, Enrico V, Matt D, Dave D, Dimitrios C, Berk B, Roberta M, Federica A, Mine AC, Julie M, Angela CB, Petr V, Doug B

Apologies: John SdS, Mischa S

Previous Actions:

  • Action, Maarten: Start a VO information in token (for accounting purposes) discussion on the Mailing list late August to revisit and converge on a plan once summer holidays are more likely to be over
    • Completed - follow up in GUT WG.
  • Action, Mischa: Mischa to look to setup a "neutral" mailing list to facilitate cross-community discussions around unified token profile
    • Completed - email inviting WLCG AuthZ to register has been sent


Proposed agenda:

Notes:

  • Various changes and discussions around developments to the token profile, but not published - notably the development of Capability sets corresponding to sets of scopes based on group memberships.
  • Another notable change is disussion around handling cases when both groups and capabilities are present - not handle the union of these, and instead take capabilities as preferred.
  • Maarten encoruages the group to go through and review and comment any issues you may have
  • The aim is to then close these in the coming weeks, in order to publish a new version early 2024
  • There are also a number of open issues from ~August. These highlight ambiguities or issues with existing wording
    • Suggestions are in pull-requests with discussions in those comments
    • The majority of these should have easy resolutions
    • Some larger issues could be postponed for a later version.
  • Proposal is for an updated V1.1 of the document
    • The plan is to publish on Zenodo and similar, and demonstrate that 1.0 is superseded
    • This should not have a 2.0 version, as it does not break anything detailed within the published 1.0 version
    • In order to avoid deployment issues, Maarten suggests we avoid changing the profile version number when working on backward-compatible issues
  • Suggested targeting before the end of March for new profile version

Token Lifetimes in the profile:

  • Maarten shared the view that the existing lifetimes in the profile are unimplementable, and rather that a certain range may be desirable
  • Potentially previously dominated by pure security concerns around lifetimes without considering operational concerns.
  • Looking for the middle ground between shorter secure lifetimes and longer lifetimes for operational usage
  • We should make sure to use other tools to control the danger of stolen tokens - notably the scopes and the audience 
  • Maarten will open an issue for further discussion on this topic
  • Francesco: are the lifetime concerns related to issuing rates?
    • Maarten: not really, the current rates seem acceptable
    • the intention should be that experiments do not rely on high token rates
    • Operational stability should mean that if there is a 2 hour downtime, there should not be any obvious major fallout
    • And the length of tokens here should consider the different workflows each experiment may require
    • Aim for a set of ballpark figures and refine these per workflow
    • resultingly - the profile needs an update to detail that this reasoning is being considered

AOB:

  • Potential DC24 discussions?
  • IAM has been updated to 1.8.3
    • Enrico: have there been any tests on how the new version performs in production?
    • Berk: not done any major tests yet, but can do some and check and report back
    • Maarten: notably it at least did not get worse! 
    • A lot of implemented fixes were usability or bug fixes

    • Maarten: is there a reason why 1.8.x and not progressing to 1.9?
    • Enrico: holding 2.0 for when MITREid dependency has been removed
    • Francesco: noting that there are other dependencies to be removed as well

    • Stephan: notes that getting pattern handling and matching in place for a 1.9 release, so as to start working on storage areas for users
    • Francesco: something reperesenting the user name within the path for storage 
    • Maarten: noting that the profile will need to be updated to relfect this, and a parallel issue should be opened within the profile.
    • Francesco: agreed. Also in favour of standardising existing practices within this area, and looking for proof of concepts before working on the profile

    • Maarten: Steve from FTS team was playing around with the IAM instance for DTeam, and found that the setup was excessively permissive.
    • Found that he was able to anonymously set up a client, and then obtain various scopes as they were unprivileged.
    • This was due to the allowance that anyone who is a member of DTeam should be able to obtain these scopes.
    • However at this stage, anonymous clients cannot be blocked
    • As a temporary measure, the storage, compute and fts scopes have been restricted.
    • Patch developed so that the client credentials flow can only be used by members of the VO, i.e. registered users
    • No releases planned before DC24, to focus attention on changes needed for that.
    • Potentially make a release candidate for just this change, and then this docker image can be used where needed
    • Stephan notes that this may be different for different IAM - CMS does not protect read, where ATLAS does.
    • Suggestion to not rush this, and allow focus on DC24 potential issues and primarily target post DC24
    • DTeam could look at trying before DC24 if a release candidate is made available
    • To be followed up offline, and to be reported next meeting
There are minutes attached to this event. Show them.
The agenda of this meeting is empty