WLCG AuthZ Call

Thursday 25 May 2023, 16:00 → 17:00 Europe/Zurich

Previous Actions:

• A pull request to be opened to implement prototype/experimental token renew descriptions, from 23/03: https://indico.cern.ch/event/1262265/
• Ticket handling, and ticket disappeared due to auto-cleanup - to be followed up offline

Proposed agenda:

• CHEP Recap and Paper
• Issuer information in tokens

 

Zoom meeting:

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

Next Meeting: 

• TBC

Present: Andrei, Angela, Dave D, Dave K, Dimitrios, Francesco, Jeff, Jim, Julie, Linda, Maarten (notes), Mine, Mischa, Petr, Thomas

Apologies: Tom, Hannah

Notes: (please send corrections)

Most of the meeting we spent discussing how a token's VO may be determined, prompted by recent threads about the Fermilab VO having several experiments as sub-VOs and the EGI Check-in issuer being single-valued for all its VOs.

Jim stated that, in his opinion, separate VOs should not share anything, as that could complicate matters and does not look right from a security perspective. Mine replied that for the international VOs at Fermilab, separate issuers were set up, whereas the other VOs were considered local enough to be served via the Fermilab VO, adding there is overhead per issuer to take into account. Jim agreed there is a cost per issuer, but the process is well-established. John pointed out that different VOs can have different policies. Dave D replied that this discussion started exactly because 3 of the sub-VOs have different scheduling policies at sites. He then added the policy of a VO is like a configuration file that can be shared, but need not be.

Mischa then reminded us of the e-mail he sent to our list on Friday, in which he described how the group and VO concepts can serve two different purposes:

1. setting the context in which the token information is valid;
2. taking authZ decisions.

The discussion that followed is paraphrased below.

Option 1 would serve accounting, for example, while option 2 is what the WLCG token profile permits to be used instead of capabilities, or in a union with those. Last year we had a long discussion initiated by Paul, in which we concluded that a union (logical OR) of those orthogonal concepts is undesirable and that a service that understands capabilities may ignore the groups altogether. We now see a new purpose that the groups can serve, viz. option 1.

In the end, Maarten proposed we let the profile point out that the groups are primarily foreseen to provide context information, but may also be used for authZ decisions by services that have been configured to use groups instead of capabilities, as agreed between a VO and those services.

Petr pointed out the issuer would need to be checked in addition, because a VO can put anything in its groups. Maarten replied we could try to enforce a namespace policy as is done for our CAs, but it would be best not to depend on that.

Andrei pointed out EGI Check-in tokens already have a claim from which the VO can be determined ("eduperson_entitlement"): the top group is the VO. It is documented here. Francesco asked if we could do the same in IAM tokens? Petr asked if that would imply getting rid of wlcg.groups? Maarten felt the "eduperson_entitlement" syntax for Check-in is awkward, but such a change can be considered. He added we may need to have if-statements in a few places, at least in the short term, to allow us to move forward with the use of Check-in tokens in production and improve things later.

Regarding how a person's roles might need to be taken into account, Dave D replied that different roles lead to different scopes in the tokens.

Finally, Petr asked when IAM 1.8.2 will be released and Francesco replied it is expected next week, if there are no issues.