Open CelsoSantos opened 5 months ago
cc @taoxuy @lizan as codeowners
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
i'll volunteer to take a look into this
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.
I'm going to have some free time soon (in between jobs). Can I help to assess this in any way?
@derekargueta, how can I help? The issue became stale in the meantime...
This is because of a poorly documented feature of "nested claim" support. Dot is interpreted as a separator. https://github.com/google/jwt_verify_lib/blob/master/src/struct_utils.cc#L108
What would be the best way to handle this then? Should the jet_verify_lib handle these situations or should it be handled before reaching it?
I think ideally in the base lib, but I'm afraid I don't know enough C++ to handle that change nor do I know how receptive google is to PRs
I think the base library should not be interpreting the keys and let Envoy handle tree-walking.
Turns out, there's actually an open PR on the jwt_verify_lib
repo
When attempting to perform a JWT Claim to Header extraction, envoy will fail to do the extraction if the claim is a URL-like string, for instance
http://example.org/some_claim
, and the fail is possibly silently, as I've been unable to locate logs with the failure.Given a claim like
on the resulting request headers, the claim
"http://example.org/parent_token": "xyz"
will not have been extracted.Here's the
claim_to_headers
block:In order to show this, I've created a docker compose based reproduction at CelsoSantos/envoy-jwt-claim-extraction, which contains a README.md detailing the steps to reproduce and showcase the issue.
Now, there are some open questions here, namely:
jwt
logs nor others inspected. Which log should expose the error message?