-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Expose PadForwardPayloadHeader in JWTRule #50856
Comments
cc. @zirain |
Can you explain why we need this? IIUC this means we are going to take a encoded token that we said we would forward and modify it? Why? |
Another service will consume the forwarded encoded token (produced by the envoy's jwt_authn filter) via the specified header. For some implementations, decoding base64 string without padding causes an issue (for example: a legacy service owned by a different team). Setting PadForwardPayloadHeader to true makes sure the encoded value has proper padding. |
What @dio said is correct. The proxy/mesh/gateway team is often not the same team as underlying services that assume padded Base64. This is especially true when integrating onto large existing systems. Older versions of golang default to require padding. Since this flag is already present in Envoy, there's likely use cases for it and should be reasonably expected here as well? |
this sounds reasonable for me, a simple API change will help, @howardjohn WDYT? |
I am not sure it makes sense to put header manipulation rules in request
authentication. This could be solved with a simple lua filter or wasm
plugin to re-write the header into a format appropriate for the user
…On Mon, May 27, 2024, 6:17 PM zirain ***@***.***> wrote:
this sounds reasonable for me, a simple API change will help, @howardjohn
<https://github.com/howardjohn> WDYT?
—
Reply to this email directly, view it on GitHub
<#50856 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEYGXPJLVQKM7HTV4SRVKDZEPLK7AVCNFSM6AAAAABHGNQIZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZUGE4TKOBTGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Describe the feature request
Currently, when outputPayloadToHeader is specified in the JWTRule config there is no way to force padding the (base64) forwarded value. It is controlled by: pad_forward_payload_header on Envoy
jwt_auth
filter.We need this
PadForwardPayloadHeader
to be exposed inJWTRule
.As comparisons with other products, in Consul we have this field exposed here: https://developer.hashicorp.com/consul/docs/connect/config-entries/jwt-provider#forwarding-padforwardpayloadheader.
Describe alternatives you've considered
We needed to craft our own
EnvoyFilter
.Affected product area (please put an X in all that apply)
[x] Networking
[x] User Experience
The text was updated successfully, but these errors were encountered: