search

WLCG-AuthZ-WG / common-jwt-profile

A repo for the WLCG Common JWT profile document
3 stars 8 forks source link

Unclear semantics of top-level group's name #39

Open paulmillar opened 1 year ago

paulmillar commented 1 year ago

The document defines groups as forming a hierarchy, where the group name represents a path through that hierarchy. For example, the group /group-1 is a top-level group because it has no parent group, while the group name /group-1/group-a refers to a group that is has the /group-1 group as its parent group.

In the document, all the examples within the document show a top-level group having the same name; e.g., on page 17 the example shows all groups having the same cms top-level group:

"wlcg.groups": ["/cms"]

"wlcg.groups":
["/cms/uscms","/cms/ALARM", "/cms"]

"wlcg.groups":
["/cms/uscms","/cms/ALARM", "/cms"]

"wlcg.groups": ["/cms",
"/cms/uscms","/cms/ALARM"]

"wlcg.groups": ["/cms",
"/cms/uscms","/cms/ALARM"]

Similarly, the example on page 34 shows groups having the same dteam top-level group:

"wlcg.groups": [
"/dteam/VO-Admin",
"/dteam",
"/dteam/itcms"
],

Despite apparent these strong adherence to some naming convention, this convention is never specified. Any such convention is left tacit. This risks different people placing different interpretations and expectations on the semantics of the top-level group.

The document should be updated to make it clear whether there are any constraints placed on the name of groups. In particular, if there is any semantic interpretation placed on the top-level group.

If the top-level group does have some special meaning, then this meaning should be described, including making clear what constrains this places on the OP and the RP.

maarten-litmaath commented 10 months ago

The table in the Common Claims subsection provides quite an extensive description of the contents of the wlcg.groups claim, with a syntax by which group names have to abide. To a large extent it is up to a VO what group hierarchy to set up and convey to resource providers as needed. That includes the naming of any components, even that of the root group. However, in practice there exists a strong link between the groups described in our token profile and the ones defined in the VO management systems used before the advent of tokens. While those historic groups remain relevant for various use cases, the easiest is to keep using the same hierarchy also in the VO's token profile.

That said, a new VO would not have to be concerned with legacy use cases and would thus have more freedom in defining its group hierarchy. At this time, I do not see an immediate reason to impose restrictions beyond the acceptable syntax, though I suspect there might be significant consequences for the configuration of affected services if a VO happened to make a poor choice for its root group name in particular. For the time being, we might just rely on common sense and self-regulation here. After all, a VO would in any case need to make some effort to meet its resource providers halfway.

We probably should add a few sentences in the profile to summarize these notions.

What do people think?