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
- 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
- Token Profile: Open Issues and PRs
- 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
- 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.