WLCG AuthZ Call

Friday 16 Dec 2022, 15:00 → 16:00 Europe/Zurich

Previous Actions:

• Follow up on Paul's PR for Groups/Scopes in profile
• Implementation of WLCG profile token lifetimes on WLCG IAM instances
• Review of open pull requests for the WLCG Profile GitHub

Proposed agenda:

• Review Previous Actions

• wlcg.groups definition: https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/15 

 

Zoom meeting:

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

Next Meeting: 

• 13 January

Present: Doug B, Tom D (Minutes 1st half), Petr V, Francesco G, John SDS Jr, Maarten L (Minutes 2nd half), Federica A, Dimitrios C, Jim B, Alexandre FB, Tommaso D, Julie M, Andrei T, Roberta M, Mine AC, Jeffrey G, Dave D

Apologies: Linda D, Dave K, Hannah S, Dave C

 

Previous Actions:

• Follow up on Paul's PR for Groups/Scopes in profile 
  • Not aware of changes
• Implementation of WLCG profile token lifetimes on WLCG IAM instances 
  • Needs a review with a wider attendance
  • Move from 96 hours to 48 hours could be a first step, to see how that affects services, though this ties in to the support level of the service
  • Avoid rocking the boat until things are less risky
  • Infinite Refresh tokens - currently the IAM default, where profile is 30 days. ~2000 tokens in CMS
  • Currently too many tokens, Petr cannot view numbers as it causes a 500 error
  • This should be fixed soon - having this functionality broken 
  • Petr suggestion setting the WLCG Test instance to match the profile - ideally this is done now
    • Francesco will look to do this soon, so if there are issues they can be caught before Christmas break
  • Should review this when Hannah is back, and decrease lifetimes where sensible
  • Giving Andrei admin privileges to the WLCG instance for testing
    • Francesco does not object, and Petr will follow up via email.
    • Maarten to be added also
• Review of open pull requests for the WLCG Profile GitHub
  • Some have been closed, but lifetime questions remain open

Proposed agenda:

• Review Previous Actions
• wlcg.groups definition: https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/15 
• Privileged accounts - user, group manager, or admin
  • Petr asking the difference, and whether Group Manager has extra privileges within the API
  • Francesco does not know - the GM role allows the user to manage the group within IAM, but not sure if this does anything elsewhere
  • Issue with Admin priv is that any token can be used to access admin controls for IAM
  • Francesco comments it would be good for Admins to be able to see normal views as well, but that the separation is of notable importance within API
  • An issue covering this should be opened against IAM
  • Petr will also check group manager tokens
  • Will need further investigation to understand the full scope of the issue
  • Perhaps use of audience claim
  • To prevent API abuse via a token issued for other purposes, IAM must not accept the "any" audience!

 

Other discussion items:

• GUI usability issues
  • Petr reports it is difficult to find out who the admins are
  • Francesco agrees and adds the GUI has to be rewritten anyway, because of the AngularJS EOL
• Account mapping when both scopes and groups are present
  • Mine asks what the status of that discussion is?
  • Maarten replies we need to rephrase what is written in the profile to avoid both ambiguity and that services might be forced to implement something awkward
  • in a long thread on our mailing list, Paul has argued that services like dCache should be allowed to ignore the groups in favor of the more precise scopes, when the latter are present
  • the idea is that service instances that are ready for scopes should just use those, while services whose (legacy) configurations are still based on groups (and roles) will use the groups in the token
  • this also allows the same token to be used for both modern and legacy configurations
  • we need a PR that proposes a new formulation that explains these aspects properly
  • Mine asks which of the included groups takes priority?
  • Francesco answers it works the same as in VOMS: the first group is special e.g. for writing, whereas all groups are considered e.g. for reading
  • Francesco then asks why a token is allowed to list only some of the groups that a user is a member of, while VOMS always lists all of them?
  • Maarten answers this allows a VO to constrain tokens to the minimum set of groups needed for a particular operation
  • Andrei adds that DIRAC already works like that since many years: instead of relying on VOMS groups, it exclusively relies on roles that have to be explicitly asked for, exactly to avoid unpredictable side effects, and that DIRAC will probably use tokens the same way
  • Francesco replies that the membership of a group could also be used to deny access
  • Maarten answers that this was discussed 1 or 2 years ago and that the conclusion was that our kinds of services should always deny access by default and thus provide access based on attributes (scopes and/or groups) that are presented
  • Francesco then asks why the membership of a child group does not imply membership of its parent groups?
  • Maarten answers that in his recollection, this was decided to avoid that services need to parse the contents of each group string in the token; instead, they can compare them as opaque strings against ACLs etc. As a bonus, this would allow a VO to put someone just into a subgroup, should that be desirable for some reason.
• Access to the IAM configuration
  • Petr would like to see how the ATLAS IAM is configured exactly?
    • Could it be exposed through the API?
    • Or could the configuration be documented somewhere?
  • Francesco answers that VO admins could be given read access to the configuration Git repository, except that we may not want certain secrets (passwords etc.) to be exposed. VO admins could even submit PRs then. An issue should be opened on GitHub.
  • Maarten says that VOMS has always had the same problem: only the service manager can see how the service is configured.
  • He adds we may still want certain parameters to be exposed through the API in addition.
  • Francesco agrees and mentions the number of users as an example, for which there already is a request to expose it through a public API.