Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-9510

Allow JWT Claim Check against query parameters

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • 2.13.2 GA
    • Gateway
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Hide

      Mount a patched file into the pod with line 84 modified to look like the following:

      return not rule.condition:evaluate(context)

      Then configure the policy to capture the value of the jwt claim through Liquid, for example:

      {{ jwt.clientId }}

      This solution will achieve what the customer wants without altering the behaviour of the rest of the policy

      Show
      Mount a patched file into the pod with line 84 modified to look like the following: return not rule.condition:evaluate(context) Then configure the policy to capture the value of the jwt claim through Liquid, for example: {{ jwt.clientId }} This solution will achieve what the customer wants without altering the behaviour of the rest of the policy

      Currently it's not possible to implement a JWT Claim Check policy that compares a jwt claim against a query parameter.

      For example
      URI: https://example.com/?check=foo
      JWT: `

      { ... "check": "foo" }

      `

      It would be expected that you could configure the policy with the following operation values:

      "jwt_claim_type": "plain"
      "jwt_claim": "check"
      "value_type": "liquid"
      "value": "{{ query_args['check'] }}"

      However this is not possible because the query string or parameters are not available in the liquid context for value field. This is because only the jwt context is provided to the liquid rendering here:

      https://github.com/3scale/APIcast/blob/4a71c1d762cc4a3e57f05b6813daec4294e24a0d/gateway/src/apicast/policy/jwt_claim_check/jwt_claim_check.lua#L84

      I found that the `uri` variable does also exist because the `get_uri` method is explicitly called here: https://github.com/3scale/APIcast/blob/4a71c1d762cc4a3e57f05b6813daec4294e24a0d/gateway/src/apicast/policy/jwt_claim_check/jwt_claim_check.lua#L61

      However it doesn't include the query string. It's possible that we could follow a similar approach using the `get_uri_arg` method: https://github.com/3scale/APIcast/blob/e7f6ebbf15d1b053283f0d77ae7176e1c7bfcb44/gateway/src/apicast/policy/routing/request.lua#L22

              Unassigned Unassigned
              rhn-support-spoole Shannon Poole
              Eguzki Astiz Lezaun Eguzki Astiz Lezaun
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: