-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client token header removal #11
Comments
Here's a bit more detail about what's happening. The instance config below tells Istio to extract the client token (the value of the "ids-dth" HTTP header of the incoming request) and put it into the
If you hit your local Minikube cluster (see README.md for our setup) with a token in the request:
The adapter gets passed the "ids-dth" header value. Here's a snippet from the adapter logs:
Now you could configure our Istio virtual service to drop the request header before sending the request on to the target service:
But with this config, if you hit the cluster again with the same request
the adapter gets an empty string as seen from the logs:
It looks like the header gets chopped off before the request makes it to the target service's Envoy sidecar which then can't obviously add that header to the Too bad, I thought, we can still do this at the rule level---i.e. in the adapter's rule config that ties the handler to the instance---or can we? With this config
and the |
Note to self. I've just bumped into this Istio wiki entry where they remove the header using a The wiki entry was last edited on 21 Nov 2018 so at sometime in the past the rule approach outlined in my earlier comment must've worked. The plot thickens... |
We'd like to be able to ditch the request IDS-DTH header with the client token before passing on the request to Orion. It looks like that isn't the easiest thing to do with Istio if our adapter should be able to access the header's value---which it should since we've got to validate the token!
As things stand now, if we remove the header through Istio configuration then the header value (token) the adapter gets to see is an empty string. Hence token validation would always fail (even for valid tokens!) if we removed the IDS-DTH header from the request.
Since we've got to validate tokens, at the moment we are not removing the header from the client request and that header will also be in the request the Envoy forwards to Orion. Is there any way to have both token validation and header removal?
The text was updated successfully, but these errors were encountered: