JWT claim check policy: uri was not escape correctly

[tkan145]

What:

Fix THREESCALE-10308

The uri was not escaped correctly with JWT claim check policy so the mapping rule will not work as expected.

For example: Mapping rule: /api/{id}/whatever is supposed to match /api/ 123/whatever and perform the JWT token check but due to the special character (space) the request will not match on resource and APIcast
skips the JWT token check.

Comparison the behavior before and after this PR

• Mapping rule with capture group

Mapping rule:  /foo{id}/bar

Request	Direct to APICast	JWT Claim Check policy	PR#1428
GET /foo/bar	False	False	False
GET /foo1/bar	True	True	True
GET /foo%201/bar	True	False	True

• Mapping rule with % character

Mapping rule:  /foo%20/bar

Request	Direct to APICast	JWT Claim Check policy	PR#1428
GET /foo/bar	False	False	False
GET /foo1/bar	False	False	False
GET /foo%20/bar	True	False	True

• Normal mapping rule

Mapping rule:  /foo/bar

Request	Direct to APICast	JWT Claim Check policy	PR#1428
GET /foo/bar	True	True	True
GET /foo1/bar	False	False	False
GET /foo%20/bar	False	False	False

With:

True   : mapping rules match

False : mapping rules do not match

Verification steps

• Setup Keycloak instance, realms, clients and users
• Install 3scale
  • Integrating 3scale with Red Hat Single Sign-On as the OpenID Connect identity provider
• Configure a single Product A with an OpenID Provider + realm A and with the following mapping rule

/groups/{groupid}/foo$

• Configure a JWT Claim check policy with the following:

{                                                                           
  "name": "apicast.policy.jwt_claim_check",                                 
  "configuration": {                                                         
    "rules" : [{                                                             
        "operations": [                                                     
            {"op": "matches", "jwt_claim": "{{roles | join: '|'}}", "jwt_claim_type": "liquid",
            "value": "invalid"}                               
        ],                                                                   
        "combine_op": "and",                                                 
        "methods": ["GET"],                                                 
        "resource": "/groups/{groupid}/foo$"           
    }]                                                                       
  }
},     

• Start dev environment

make development
make dependencies

• Run apicast locally

THREESCALE_DEPLOYMENT_ENV=staging APICAST_LOG_LEVEL=debug APICAST_WORKER=1 APICAST_CONFIGURATION_LOADER=lazy APICAST_CONFIGURATION_CACHE=0 THREESCALE_PORTAL_ENDPOINT=https://token@3scale-admin.example.com ./bin/apicast

• Generate token from a realm A
• Run query with the valid jwt

# capture apicast IP
APICAST_IP=$(docker inspect apicast_build_0-development-1 | yq e -P '.[0].NetworkSettings.Networks.apicast_build_0_default.IPAddress' -)

curl -v -k -H "Host: example.com:443" -H "Accept: application/json" -H "Authorization: Bearer ${ACCESS_TOKEN}" "http://${APICAST_IP}:8080/groups/%201/foo"

• The response should be HTTP/1.1 403 Forbidden

< HTTP/1.1 403 Forbidden                     
< Server: openresty                          
< Date: Tue, 28 Nov 2023 02:44:27 GMT        
< Content-Type: text/plain                   
< Transfer-Encoding: chunked                 
< Connection: keep-alive                     
<                                            
Request blocked due to JWT claim policy      
* Connection #0 to host 127.0.0.1 left intact

[tkan145]

It seems like this is the only place we use context:get_uri(), does anyone know why we use context:get_uri() instead of ngx.var.uri?

[eguzki]

It seems like this is the only place we use context:get_uri(), does anyone know why we use context:get_uri() instead of ngx.var.uri?

I wonder if this is the method being called https://github.com/3scale/APIcast/blob/master/gateway/src/apicast/policy/load_configuration/load_configuration.lua#L19-L23

get_uri = function(self)
      if self.route_upstream then
        return self.route_upstream.uri.path or "/"
      end
      return ngx.var.uri
    end,

So the routing policy could override the uri path?

[eguzki]

Verification steps worked.

I have also run same verification steps with the APIcast version of current master branch and the request hits upstream service

[tkan145]

I wonder if this is the method being called https://github.com/3scale/APIcast/blob/master/gateway/src/apicast/policy/load_configuration/load_configuration.lua#L19-L23

Yes. that is the one.

Thank you for the code-review. I will merge this now.