Feature proposal: dynamic server_token_id propagation from request URL

It’s been a long time since the last issue =D

We did another hack to your source code and want to discuss if you think something similar to our hack may be turned into a feature. I will try to explain and would like to hear your thoughts about this. I know it may be too specific to our use-case but let’s see.

Last successful setup:

1. Single eas server
2. Many envoy filters where we specify token_id per tenant which has to be retrieved from redis. Each filter is applied to istio sidecar, so to specific app, not in general to all publicly exposed services behind ingress.
3. Single redirect_url for all tokens

Ignoring the why, we thought it would be great to retrieve token dynamically from request subdomain (or URL path for that matter). Then, we can use single filter on ingress level to handle different tokens (token name = tenant name), not on specific sidecar of the service.

So, my colleague added this piece of code to server.js:

if (easVerifyParams.config_token_regex) {
      let matches = req.get("host").match(new RegExp(easVerifyParams.config_token_regex))
      if (matches && matches[1]) {
        easVerifyParams.config_token_id = matches[1]
      } else {
        externalAuthServer.logger.error("config_token_regex: unexpected number of matches (%j)", matches)
      }
    }

and then we changed envoyfilter config to this:

headers_to_add:
- key: x-eas-verify-params
   value: '{"config_token_store_id":"primary", "config_token_regex": ".*\\.(.*)\\.k8s.*"}'

Basically, we are using regexp to get token name from URL. Then, you can split applications (or tenants, or users) with a single filter if some part or URL matches config_token_id.

The last important bit is that we had a single redirect URL for all tokens like https://istio-eas.hal24k.nl/oauth/callback

It caused a problem like this:

1. During initial request, starting verify pipeline logic was working fine because request host was https://jupyterhub.tenant-354.k8s.dimension.ws/hub/spawn and we could capture regexp group.
2. After logging in to OIDC, the host header would be https://istio-eas.hal24k.nl/oauth/callback and starting verify pipeline would not extract config_token_id and the rest would fail.

So, while configuring token, we use specific redirect URL per tenant and point all of them to eas service. The only reason for that is to get tenant name in the host header.

So, current working set up:

1. Modified eas server
2. Single envoy filter on ingress level with token_id_regexp
3. Many redirect_url per tenant with include tenant name in the host (but could be url path as well)

Please let us know if you find this interesting and maybe you have better idea how to set this up. So, this could be like another case for config token logic - to use regexp.

[travisghansen]

Oh wow that’s a great use case for request_js! I had not thought of that.

[travisghansen]

Yeah that sounds much better. The reason I advise against the first use case is that would require every single config token ever issued to have the rule embedded…seems like the ‘wrong’ place to handle the issue. Your last comment seems like the ‘right’ place to handle the issue. It will work, just seems like a maintenance nightmare.

The feature is directly geared at the second use case you mentioned.

In either case, if you need some input getting it going let me know!