OIDC: Aggregated and Distributed Claims

[universam1]

Is your feature request related to a problem? Please describe.

For OIDC (using filter oauthOidcAnyClaims ) with Azure AD we are seeing users who are member of many groups to run into a clipped groups token behaviour of Azure.
The groups claim is replaced by hasToken and a pointer to the Graph API.
That breaks subsequent filter oidcClaimsQuery for group membership, as the expected claim of groups is empty

Describe the solution you would like
Skipper detects this flag hasToken and performs a lookup to the Graph API, retrieving the actual list of groups, storing in the statebag or cookie.
It could be a configurable option to perform this lookup.

Additional context (optional)
Would it make sense to implement this lookup to the Graph API, granted this looks like a Azure-ish behaviour?

Which filter would be the proper place to extend?

Would you like to work on it?
Potentially, with support.

[szuecs]

When I check the linked resource, there is:

{
  ...
  "_claim_names": {
   "groups": "src1"
    },
    {
  "_claim_sources": {
    "src1": {
        "endpoint":"[Url to get this user's group membership from]"
        }
       }
     }
  ...
}

I think if we somehow configure that lookup key is _claim_sources.<any>.endpoint it could be done.
Great would be to research how other OpenID Connect providers handle this case. I don't know, maybe they just limit it. It would be great information of how we should generalize this case.

[universam1]

It as actually a well defined standard behaviour:
https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims

Example implementation:
https://github.com/hashicorp/vault-plugin-auth-jwt/blob/b724ae7ef01864b4f931814d75b875252076936e/provider_azure.go#L51-L64

or: https://github.com/grafana/grafana/blob/main/pkg/login/social/azuread_oauth.go#L167-L183

For other IdP we've seen with ADFS that case is not properly handled eventually causing browser or LB exceptions, no idea about others though.

The Hashicorp example looks well implemented as a good base - what do you think @szuecs ?
Since only oauthOidc*Claims filters have credentials would this be the right filter to extend?

[webframp]

If it's part of the oidc standard then it seems potentially useful to implement to me. Interestingly both referenced example implementations look like they were able to be implemented using golang.org/x/oauth2 without requiring any azure specific implementation library. That's a nice design goal I would think.

Although some nice libraries like https://github.com/manicminer/hamilton/ exist, it would not seem very nice to require that just to support this feature.

[szuecs]

If it's part of the spec let's build it of course!
So I guess we should put the aggregated data into our container that we pass to stateBag which can queried via oidcClaimsQuery or how do you think to integrate it?

https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample , 5.6.2.2 is in particular an interesting case. We need to query the sources, but this should be done in oauthOidc*Claims to provide a "provisioned" stateBag for oidcClaimsQuery.