dynamic AuthConfig selection or dynamic AuthConfig values

bcollard commented 2 years ago

Version

1.11.x (beta)

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

In a multi-tenant context, I would like to dynamically select the AuthConfig that is applied to a shared route (among tenants).

Relying on some headers in the request, I'd like either:

to use these headers as labels to select the tenant's AuthConfig
pass these headers as-is or as context metadata in the Authorization request to the ExtAuthz server, so that the ExtAuthz server dynamically select the right AuthConfig
use the same AuthConfig for all the tenants, but in a dynamic way: for instance, the options for the OIDC plugin would not be hardcoded but picked from the AuthZ request headers or metadata

⬆️ these are implementation ideas I've today but feel free to implement things from a different angle!

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional Context

No response

sam-heilbron commented 2 years ago

Current workaround: lots of duplicated routes

bcollard commented 2 years ago

given the current use cases in the field, I would push for the 3rd bullet point to be implemented at first. Then either point number 1 or number 2.

antonioberben commented 2 years ago

Another customer is interested in this feature. Thanks

marcelsigner commented 2 years ago

I suggest to split into 2 extensions.

Support of multiple AuthConfigs where the AuthConfig is selected via a regexPath

If the requestURL matches with the regexPath defined in the AuthConfig, the AuthConfig is used. According to AuthConfig it may already contain an array of configs. But there is no selection possible based on the entryURL. This first extension prevents from duplicating all the routes.

Support of loading the AuthConfigs from an external server

Configure where to get the AuthConfigs. It could look like the following: "AuthConfig": { "clientSecretRef: { "name": "", "namespace": "" } "authConfigEndpoint" : "https://domain/authserver/glooAuthConfig" "discoveryPollInterval": { "seconds": 0 }, } This means:

AuthConfigs have to be loaded from the authConfigEndpoint
Basic Auth required for the authConfigEndpoint, credentials are at clientSecretRef
discoveryPollIntervall defines how often to reload the authConfig from external server and refresh the config.
Whenever the authConfig is loaded and applied, the issuer_url (.well-known/openid-configuration) also needs to be refreshed for every oauth2 config.
With that all AuthConfigs are always available on Gloo Edge when needed. No delays when processing requests. This seems to be the current strategy.
Attached a possible example (only taking in account "OidcAuthorizationCode" DynamicAuthConfigForGlooEdge.yaml.txt ) A workshop might be a good idea to refine the solution approach.