Use Case: Multiple VOs supported by a "common implementation"

[jbasney]

The profile mentions that "it is hoped that a common implementation can be used (analogous to how VOMS-Admin is operated at CERN)." We are trying to follow this example with CILogon. We have a single token endpoint (https://cilogon.org/oauth2/token) that serves multiple VOs. According to the profile, we need to set the iss claim to match the user's VO. However, a user may be a member of multiple VOs. Also, we have a case where a single OAuth client_id (Vault at Fermilab) is being used by users who are members of multiple VOs.

How do we know which VO to put in the iss claim?

Do we need to have a different token endpoint per VO? A different client_id per VO?

Fermilab wants us to support VOs being dynamically added/removed over time, so forcing us to instantiate new token endpoints or client_ids when a new VO is added would be cumbersome.

In any case we need to instantiate a discovery endpoint for each issuer, but that's something we can do dynamically.

Ideally we could have a request parameter to specify the user's selected VO (e.g., wlcg.groups).

This is a use case I had in mind for pull request #6.

[msalle]

I think there has been confusion / the document is not clear. I'd say in a multi-tenant scenario you'd just have the same issuer for the different VOs. Our thoughts were that each (CERN-experiment) VO would typically run their own Authorization Server, and as such would be the typical issuer for the tokens. The iss claim should match the issuer of the tokens and typically be what you would get from the well-known endpoint for the Authorization Server and therefore cannot be really made different depending on the user and/or flow.

[jbasney]

Yes, simply using "iss": "https://cilogon.org/fnal" as the issuer for all Fermilab VOs would certainly simplify things on the CILogon side! In that case, I don't think we'd need the user to choose a VO. Instead, the user can simply request the capabilities they need, and CILogon can grant the capabilities based on the user's various Fermilab VO memberships.

[msalle]

Except that as a user you might not want all of those, and some might even be conflicting, so basically the 'active role selection' requirement from FIM4Rv2. So I think https://cilogon.org/fnal should probably allow the user (probably after coming back from authenticating at the home IdP) to select which groups/roles/capabilities to express in the resulting token?

[jbasney]

Right, the user is still specifying a least-privilege list of capabilities in the "scope" request parameter.

[msalle]

Probably we should discuss this in one of the PRs but I can imagine that you don't always want to do this already in the first /authorize request, since that would put the burden of asking the user on the end-service. Instead you might want to do this at the proxy after the user is authenticated. And then you cannot do it with the "scope" request parameter in the initial request. Or do envision using a token exchange for that?

[jbasney]

Yes, we are using token exchange for cases where the scopes can not be sufficiently limited in the first /authorize request. For now, we do not provide an interface on the /authorize endpoint for editing the requested scopes. Is there a WLCG Profile implementation that allows editing scopes on the /authorize endpoint?

Since this use case is focused on capability-based authorization and not group-based authorization, does "the 'active role selection' requirement from FIM4Rv2" apply? If so, that seems to bring us back to pull request #6 where we're combining roles and capabilities into one use case.

[DrDaveD]

The capabilityset request from PR #10 is certainly able to select different 'iss' values for different VOs (and the document currently explicitly includes that) but the question is still open of whether or not it is necessary to have a different value for every VO. I don't know if it's something we can know for sure at this point. How about if we just make it optional, to be decided later? In yesterday's disccussion @andreaceccanti seemed to assume that it was necessary, but I don't know why.

[jbasney]

Yes, I hope we can discuss this use case on a future WG call and add some clarifying text to the profile about it. I understood @andreaceccanti as saying yesterday that we need to have a different authorization_endpoint and token_endpoint for each VO, which would add a lot of management overhead to supporting Fermilab's multiple VOs, especially as the VOs are added/removed somewhat dynamically.

A single issuer, authorization_endpoint, and token_endpoint for all the Fermilab VOs ("sub-VOs"?) would be much simpler, so I'd like to understand any reasons why that wouldn't be acceptable under the profile. Since the user's VO membership(s) will determine the scope values in the token, I'm not sure why the VO (or "sub-VO") also needs to be identified by the iss value. Simply using "iss": "https://cilogon.org/fnal" for all Fermilab VOs is my preference.

[andreaceccanti]

There's no concept of multi-tenancy in the WLCG JWT profile. By design, the issuer is the VO and an OAuth/OIDC authorization request is always targeted at a specific issuer token endpoint. The main reason is that we do not implement a VO selection protocol on top of oauth.

Also I really don't see the implementation overhead argument. You can structure your code in a way that supports a "parametric" token endpoint, and support your dynamic, multi-vo scenario.

As as example take the Keycloak realm implementation.

[DrDaveD]

But with wlcg.capabilityset we now do have a VO selection protocol. Right? That's for capabilities; for group-based, we have it with wlcg.groups.

[andreaceccanti]

I think the capabilityset functionality meaning shouldn't be overloaded. It's not a VO or token issuer selection mechanism. It's a way to request a set of scopes defined in the context of a token issuer (which, for the WLCG JWT profile, is a VO).

[jbasney]

There's no concept of multi-tenancy in the WLCG JWT profile.

I think the part about "it is hoped that a common implementation can be used (analogous to how VOMS-Admin is operated at CERN)" is what introduces the concept of multi-tenancy, though I admit to being ignorant about how VOMS-Admin is operated at CERN.

[andreaceccanti]

Indeed a common implementation is used. And even a single multi-tenant implementation can be used. But for the profile, the issuer is the VO. We can discuss and revisit that, but that's the point!

[DrDaveD]

Keep in mind that having a different "iss" claim in the access tokens for every VO requires a multi-tenant installation to support corresponding web services with a .well-known/openid-configuration for each VO. That's what Jim would like to avoid doing if there's no good reason for it. Will anybody be looking at the "iss" field in the access token to distinguish one VO from another?

I don't think that choosing different VOs with wlcg.capabilityset is an overload of its functionality. It's the same thing as selecting different roles within a VO -- it maps a user to a different set of capabilities.

[andreaceccanti]

Will anybody be looking at the "iss" field in the access token to distinguish one VO from another?

Yes! That's the whole point!

If you re-read the profile it will be evident. The implications are not only on the token issuer, but mostly on the resource servers.

We can revisit and re-discuss this (don't tell @bbockelm ...), of course, but then we will have to standardize on claims used to identify the VO and on scopes used to select the VO.

[maarten-litmaath]

Hi all, today each VO has its own VOMS-Admin service(s) and I would advise we do the same for IAM, to allow different VOs to be served by their own, separately hosted endpoints. In particular this would allow high-rate VOs to be split off and not interfere with other customers. Am I missing sth?

[andreaceccanti]

Multi-tenancy is a token issuer deployment decision. The profile, OTOH, defines the basic concepts underlying authn/z in WLCG, in a way that is orthogonal to the actual implementation and deployment.

A central concept is that the token issuer is the VO.

By choosing that the token issuer is the VO, the WLCG JWT profile basically creates an authN/Z namespace for a VO around the issuer URL. This means that if a client trusts, for example, the "https://cms-auth.web.cern.ch" token issuer, it is sure that all tokens issued by that issuer are relevant to the CMS experiment.

This is handy as we do not have to define ways to select a VO or impose other mechanisms to the clients to determine what is the VO linked to a token.

Depending on the flexibility of the token issuer software, this scheme can be implemented with a single instance serving multiple VOs, i.e. whether to use a single instance serving multiple VOs or separated instances it's a deployment decision.

[DrDaveD]

Jim and I were investigating this together late last week and noted that currently with VOMS at Fermilab there are only three hosted top-level VOs: "fermilab", "des", and "dune". There are more than 20 sub-VOs under the "fermilab" VO. I am thinking we could translate that directly to tokens. The fermilab "VO" would associate to one "iss", but within that the sub-VOs would only vary in their capabilities and there would be no specific identification of the sub-VOs.

[jbasney]

I'm going to close this old issue of mine now. I think it is resolved. Pull request #6 is merged. CILogon is now operating a single token endpoint (https://cilogon.org/oauth2/token) that serves multiple VOs with per-VO iss values. Each client_id is associated with a single VO, so CILogon can set the iss value (and other claims) appropriately based on per-VO policies.