Document does not stated clearly that an issuer supports a single VO

[paulmillar]

From email discussions, I recall that the document was written with the assumption that an issuer (an OP) supports exactly one VO.

Indeed, from my perspective, this assumption has quite wide-reaching consequences; for example, it drives how capabilities are expressed (in the scope claim) and how group-membership is expressed (in the wlcg.groups claim). I believe these aspects of the standard will no longer support their intended use-cases if this exactly-one-VO assumption is violated and an issuer will issue tokens to members of multiple VOs.

Therefore, this exactly-one-VO assumption is actually a strong requirement.

Unfortunately, this requirement is stated explicitly in the document. The closest (that I could find) is a parenthetical statement contained in an example. On page 20, the document states:

A typical storage service must be able to map a token issuer (which corresponds to a single VO) [...]

Given the important this requirement, I think the document should be updated to make it very clear that a issuer MUST (RFC 2119) only issues tokens for a single VO.

[DrDaveD]

It depends on what you mean by a VO. If they're all administered by the same people and have all the scope paths in a shared namespace, you could consider that a single VO even if there are "subVOs" under that. That's exactly how the fermilab VO is currently managed in production use, with a single issuer that issues scopes with storage paths and wlcg.groups beginning with the name of the subVO.

[paulmillar]

Thanks for sharing you comments @DrDaveD .

You raise a good point! The document doesn't define what is a VO. This makes any such discussion on this topic rather difficult. I've opened a separate issue on this point (see #38).

That said, there's no concept of a sub-VO in the document. If that is something we should consider then a definition of a sub-VO should be added. This could be part of #38, or tackled as a separate issue.

Under my current understand of the document (as-is), the Fermilab deployment is a single VO (let's call that VO "fermilab", for example). The different top-level groups are just that: groups within this single "fermilab" VO.

However, this interpretation is only my personal point-of-view. The document does not define the semantics of the top-level groups at all (see #39), despite strongly hinting that this is the VO name in the examples.

As above, I fear discussing this topic further will be difficult without first resolving #39.

[marianne013]

This is actually a major problem for e.g. GridPP (UK), which currently supports 20+ VOs on their (three) voms servers. As you would expect, each VO is administered by (different) VO admins We really rather not have 20+ IAM (x3 for redundancy ?) IAM servers. I spoke to one of the IAM developers recently at a RAL hackathon recently and they seemed to be at least open to discussion about supporting multi-VO IAM. I know it's not the LHC use case, but there's a whole eco system in distributed computing out there, often for communities which do not have the LHC level of computing support, that has come to rely on x509 and those unilateral decisions (#worksforLHC) pose a major problem.

[paulmillar]

The TL;DR: the "issuer supports a single VO" statement does not prevent supporting multi-VO deployments on a single node. Supporting multiple communities on a single server is pretty standard in other contexts.

At the risk of saying what everyone already knows, here are some thoughts ...

The "issuer" is an HTTP endpoint. I think it is important to distinguish between the "service" and "endpoint". The service is some software running on a (possibly a single) server/node. The "endpoint" is an HTTP resource, which implies it has a corresponding DNS entries, server(s) that can present a suitable TLS certificate, network connectivity, etc. So, service (the hardware + software) and endpoint (the accessible HTTP resource) are somewhat decoupled concepts.

To be a bit more concrete, a single service can support multiple endpoints (or "issuers" in our context) in multiple ways. Here are some examples:

• different paths; for example, https://issuer.example.org/foo/ for VO "foo", https://issuer.example.org/bar/ for VO "bar".
• different port numbers; for example, https://issuer.example.org:8440/ for VO "foo", https://issuer.example.org:8441/ for VO "bar".
• different hostnames (similar to virtual hosts); for example https://foo.issuer.example.org/ for VO foo, https://bar.issuer.example.org/ for VO bar.

(There may be other approaches)

All these three approaches are theoretically possible on a single server node. However, I cannot say which (if any) of these approaches are already supported by Indigo-IAM (or other software), or how much effort it would take to add support (if missing).

For production deployments, OIDC is based on standard HTTP requests, so standard approaches should apply for making a service scale and robust.

[maarten-litmaath]

Hi all, even if each VO were able to get its own IAM instance (which I deem unrealistic), there would still be EGI Check-in and/or Fermilab sub-VOs (and possibly yet others) that shared services at our sites will have to support besides IAM VOs. Therefore it looks undesirable to hang on to the simplistic notion of the issuer solely identifying the VO. That recipe could still serve either as a starting point or as a fall-back when the VO could not otherwise be determined from a token.

[paulmillar]

Hi Maarten,

even if each VO were able to get its own IAM instance (which I deem unrealistic)

Just to be clear, I don't think anyone has ever said that a VO must have its own IAM instance.

The document (I strongly believe) doesn't have this requirement. Nobody is suggesting we change this.

The document suggests each issuer supports a single VO. (issuer != IAM instance).

Fermilab sub-VOs

The document currently makes no reference to sub-VOs. If we anticipate supporting the sub-VO concept then someone would have to define what is a sub-VO, and how this information is conveyed within the token.

Personally, I don't really understand the sub-VO concept: I guess they're "child" VOs of some parent VO (i.e., forming a hierarchy). However, it's unclear (to me) what exactly is the relationship between a sub-VO and its parent VO?

• Does membership of a sub-VO imply membership of the parent VO? If so, does this get asserted somehow, or is it implicit?
• Can a sub-VO have another sub-VO as a parent, or is the parent always a (top-level) VO? Does the VO hierarchy have a maximum depth of 2?
• Is there any relationship between sibling sub-VOs, beyond sharing a common parent VO?
• How does the VO hierarchy relate to the group hierarchies?
  • Does a sub-VOs and its parent VO share a common group hierarchy, or
  • Does a sub-VO include its parent VO group hierarchy but can have its own groups, or
  • Does a sub-VO and its parent VO have completely independent group hierarchies?
• Conceptually, how is a sub-VO different from a top-level group of its parent VO?

undesirable to hang on to the simplistic notion of the issuer solely identifying the VO

Sure, that's a fair conclusion.

However, this is unrelated to this issue.

What you describe is (to me) identifying a limitation with the current approach, based on real-world feedback. This is a problem we should acknowledge and fixed. I suspect that adopting such a change will have a non-trivial impact on the semantics of AuthZ statements, and consequently their syntax.

Therefore, I would suggest the following approach:

1. create a new issue (something like "allow an issuer to support multiple VOs")
2. update the document to make it clear that the document currently requires an issuer supports a single VO (closing this issue).
3. start work on an update to the document that allows a issue to support multiple VOs.

Step 1. is just acknowledging and recording your conclusion. It allows for a discussion on how to achieve this.

Step 2. is also rather trivial: just changing adding a single sentence, which shouldn't have any impact.

Step 3. could involve modifying the format of claim values: a non-backwards compatible change. This is fine, but may need some time and discussion before it's ready to be adopted.

That recipe could still serve either as a starting point or as a fall-back when the VO could not otherwise be determined from a token.

Determining the VO (if an issuer supports multiple VOs) is certainly a concern; however, the problem is actually somewhat deeper than this.

The current AuthZ statements forces a resource provider to allocate resources (i.e. delegate AuthZ decisions) to the issuer. The "issuer supports a single VO" statement gives us the desired ability for sites to allocate resources to a particular VO.

Therefore, we would probably either need to make breaking (non-backwards compatible) changes to support this.

This is all fine, but (I think) should be handled as a separate issue.

I believe this issue is actually just a trivial concern: just documenting the status quo.

[DrDaveD]

I think a Fermilab sub-VO is pretty much the same thing as a top-level group as far as tokens are concerned. There may be groups under that, but we never nest sub-VOs under sub-VOs.

In other contexts sub-VOs do have their own resources, for example most of them have their own cvmfs repository.

[msalle]

Few short remarks:

• we call it a VO but what we basically are missing is something that sets the analogue of a SAML scope (or call it namespace) of the attributes, so something that defines within which domain the attribute meaning is defined/unique. This is particularly clear for the capabilities but also for the groups (and is why the toplevel group in VOMS typically was the VO name). This is also relevant for whether we need a definition of VO: in VOMS the VO is basically that, it's the body that determines the scope/namespace. I'll comment in #41 about that.
• I think we never strictly speaking decided that there would be 1-to-1 correspondence between VO and issuer. The thinking was more that there typically would be (roughly) an issuer per VO. I think we see enough use cases/problems for letting that idea go completely, so I agree with @paulmillar 's 3 steps.

[maarten-litmaath]

Please check #47 that tries to address the aforementioned concerns to some extent.