You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently make use of Kong to set a number of "trusted headers" on requests that are to proxied to upstreams. This works fine if we can guarantee that the upstream will only ever accept requests from Kong. However, in on boarding some legacy applications we can no longer guarantee this and hence, I started looking into this plugin. This solves 95% of the problem but the signed JWT token does not guarantee that the other header's haven't been tampered with, nor does it prevent someone from re-using the token with a different set of headers within the 1 minute time interval that it is valid for. Thus, I have been looking for a way in which I could set custom claims using this plugin - as these are covered by the token signature and thus far less prone to spoofing.
At first I approached this by setting a custom value on the ngx context which was then read by this plugin. However, I don't like the mixing of code dependencies between plugins. So, I then settled on adding new a schema option that allow the user to specify that this plugin should convert a configurable set of headers into custom claims on the JWT token with the option of clearing the header after adding it as a claim to the JWT payload. Will submit a PR with this implementation. Would love to hear your thoughts on this approach or if you can think of a better one.
The text was updated successfully, but these errors were encountered:
We currently make use of Kong to set a number of "trusted headers" on requests that are to proxied to upstreams. This works fine if we can guarantee that the upstream will only ever accept requests from Kong. However, in on boarding some legacy applications we can no longer guarantee this and hence, I started looking into this plugin. This solves 95% of the problem but the signed JWT token does not guarantee that the other header's haven't been tampered with, nor does it prevent someone from re-using the token with a different set of headers within the 1 minute time interval that it is valid for. Thus, I have been looking for a way in which I could set custom claims using this plugin - as these are covered by the token signature and thus far less prone to spoofing.
At first I approached this by setting a custom value on the ngx context which was then read by this plugin. However, I don't like the mixing of code dependencies between plugins. So, I then settled on adding new a schema option that allow the user to specify that this plugin should convert a configurable set of headers into custom claims on the JWT token with the option of clearing the header after adding it as a claim to the JWT payload. Will submit a PR with this implementation. Would love to hear your thoughts on this approach or if you can think of a better one.
The text was updated successfully, but these errors were encountered: