Support dynamic JWKS server URL

jmunozro commented 2 years ago

Version

1.10.x (latest stable)

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

As it is today, the JWKS server URL has to be explicitly defined in the VirtualService spec. We can specify multiple URLs by specifying multiple providers but in the end, the list of URLs needs to be known in advance.

In our case, the upstream is a multi-tenant application.

It means that we have a global JWKS domain (e.g. authentication.mycompany.com) and each tenant has its own subdomain that provides its relevant JWKS (e.g. tenantA.authentication.mycompany.com, tenantB.authentication.mycompany.com, etc).

We would like to extract the URL from the 'jku' header, validate it matches the global domain (will be specified in the VirtualService), and if it's valid, get the JWKS from there (in case it's not already present in the cache).

Describe the solution you'd like

No response

Describe alternatives you've considered

implement a custom authorization server can be a solution, but our preference is to reuse the existing battle-tested native extension.

Additional Context

This may require significant effort as envoy does not seem to be designed to allow it: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter

chrisgaun commented 2 years ago

Need estimation if we can do this in Gloo or does it require upstream change in Envoy.

chrisgaun commented 2 years ago

Need to understand level of effort on this one @sam-heilbron

nfuden commented 2 years ago

Initial ad-hoc musings when this was first brought up https://solo-io-corp.slack.com/archives/CEDCS8TAP/p1647954703377459?thread_ts=1647950777.785059&cid=CEDCS8TAP Basically it doesn't seem to make sense via straight envoy changes but two initial thoughts were:

If we could perform discovery on the subdomains then we could use all the normal battle tested filters based on programmatically discovered remotes
We could implement this in ext-auth but thats different than the current jwt filter but the ask seemed to dislike the idea of ext-auth / self implementation of a custom auth server to handle it

Neither of these are trivial.

github-actions[bot] commented 4 months ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.

solo-io / gloo