-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document does not stated clearly that an issuer supports a single VO #28
Comments
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. |
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. |
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. |
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:
(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. |
Hi all, |
Hi Maarten,
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).
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?
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:
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.
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. |
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. |
Few short remarks:
|
Please check #47 that tries to address the aforementioned concerns to some extent. |
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 thewlcg.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:
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.
The text was updated successfully, but these errors were encountered: