Dynamically generated iss field for multi-VO IAM instance

[bbockelm]

(I chatted with @norealroots about this at CHEP and he suggested I write up this ticket for discussion with @enricovianello)

One power of the software (OA4MP) that powers the CILogon service is that a single instance of the software service can issue tokens with different iss fields based on the request. (I find the fact that the same word, "issuer", is used for the service that creates the token and the "attribute authority" is unfortunate).

Having a single instance be seen as several "issuers" obviates needing separate attributes for "attribute authority" (or "VO"). While solving this at the profile-level is under discussion - and raises even more complications - it's going to be far off in the future.

So, here's the proposal:

• Add a configuration parameter (let's call it "issuer_base" for discussion purposes). When enabled, the iss field is formed by concatenating issuer_base with the top-level group.
  • So, if issuer_base is https://iam.example.com/ and the user's top-level group is /cms, the iss claim is set to https://iam.example.com/cms.
  • This raises a question of "which group?" should be used for the iss string if there are multiple applicable ones. If there's not already an idea of a "primary" one, we can use the fact that the WLCG profile provides a mechanism to request a group to assert in the token. Use the first top-level group from the request and don't include the group.
• If IAM is hosting the "issuer_base" URL, then requests to $issuer_base/<grp>/.well-known/openid-configuration serves a resource with the same contents as $issuer_base/.well-known/openid-configuration.

That is, to support multiple VOs, re-arrange the contents of the claims to better comply with the WLCG profile (which clearly states one iss URL per VO) but don't change anything fundamental in IAM.

(I'll be around CHEP all week if you'd like to discuss in person)