Access to versioned API denied

Product Bug Reports
1

Hi,

If I have an unversioned API, the setup works. Authentication mode is set to JWT. There is a policy with access rights to that API. Requests get allowed or not based on whether the JWT is valid (i.e., signed correctly and has a policy claim that matches the ID of the policy with access to the API in question).

However, as soon as I version that API, I get

“Access to this API has been disallowed”

as a response.

The policy was adjusted to have access rights to the versions of the API.

These are the according log statements:

level=info msg="Attempted access to unauthorised API version." api_found=true key=587cf8f49411a405591e41b7184ca5a27caca5cc49856114e651043e origin=**** path="/drowsy/helloworld" version_found=false
level=error msg="request error: Access to this API has been disallowed" api_id=be3af4efed9c483d6b39410f784a94bb org_id=587cf8f49411a405591e41b7 path="/helloworld" server_name="http://my-server:8080/" user_id="****043e" user_ip=****

This is in the policy:

"access_rights" : {
    "be3af4efed9c483d6b39410f784a94bb" : {
        "apiname" : "My API IGR",
        "apiid" : "be3af4efed9c483d6b39410f784a94bb",
        "versions" : [ 
            "v1", 
            "v2"
        ],
        "allowed_urls" : []
    }
},

This is an excerpt from the API:

{
    "_id" : ObjectId("587cfdd99411a405591e41b8"),
    "name" : "My API IGR",
    "slug" : "0",
    "api_id" : "be3af4efed9c483d6b39410f784a94bb",
    "org_id" : "587cf8f49411a405591e41b7",
    "use_keyless" : false,
    "use_oauth2" : false,
    "use_openid" : false,
    "openid_options" : {
        "providers" : [],
        "segregate_by_client" : false
    },
    "oauth_meta" : {
        "allowed_access_types" : [],
        "allowed_authorize_types" : [],
        "auth_login_redirect" : ""
    },
    "auth" : {
        "use_param" : false,
        "param_name" : "",
        "use_cookie" : false,
        "cookie_name" : "",
        "auth_header_name" : "Authorization"
    },
    "use_basic_auth" : false,
    "enable_jwt" : true,
    "use_standard_auth" : false,
    "enable_coprocess_auth" : false,
    "jwt_signing_method" : "hmac",
    "jwt_source" : "QXZ5empQcURuQWRKYUFke3lbUWc9THlDZCNnYTZ6KkZhS01iQlQ3dEJIQks/bkhLTFg=",
    "jwt_identit_base_field" : "sub",
    "jwt_client_base_field" : "",
    "jwt_policy_field_name" : "policy",
    "notifications" : {
        "shared_secret" : "",
        "oauth_on_keychange_url" : ""
    },
    "enable_signature_checking" : false,
    "hmac_allowed_clock_skew" : -1.0,
    "base_identity_provided_by" : "",
    "definition" : {
        "location" : "header",
        "key" : "x-api-version"
    },
    "version_data" : {
        "not_versioned" : false,
        "versions" : {
            "djE=" : {
                "name" : "djE=",
                "expires" : "",
                "paths" : {
                    "ignored" : [],
                    "white_list" : [],
                    "black_list" : []
                },
                "use_extended_paths" : true,
                "extended_paths" : {
                    "ignored" : [],
                    "white_list" : [],
                    "black_list" : [],
                    "cache" : [],
                    "transform" : [],
                    "transform_response" : [],
                    "transform_headers" : [],
                    "transform_response_headers" : [],
                    "hard_timeouts" : [],
                    "circuit_breakers" : [],
                    "url_rewrites" : [],
                    "virtual" : [],
                    "size_limits" : [],
                    "method_transforms" : [],
                    "track_endpoints" : [],
                    "do_not_track_endpoints" : []
                },
                "global_headers" : {},
                "global_headers_remove" : [],
                "global_size_limit" : NumberLong(0),
                "override_target" : "http://my-server:8080/"
            },
            "djI=" : {
                "name" : "djI=",
                "expires" : "",
                "paths" : {
                    "ignored" : [],
                    "white_list" : [],
                    "black_list" : []
                },
                "use_extended_paths" : true,
                "extended_paths" : {
                    "ignored" : [],
                    "white_list" : [],
                    "black_list" : [],
                    "cache" : [],
                    "transform" : [],
                    "transform_response" : [],
                    "transform_headers" : [],
                    "transform_response_headers" : [],
                    "hard_timeouts" : [],
                    "circuit_breakers" : [],
                    "url_rewrites" : [],
                    "virtual" : [],
                    "size_limits" : [],
                    "method_transforms" : [],
                    "track_endpoints" : [],
                    "do_not_track_endpoints" : []
                },
                "global_headers" : {},
                "global_headers_remove" : [],
                "global_size_limit" : NumberLong(0),
                "override_target" : "http://my-server:8080/"
            }
        }
    },
    [...]
}

First I thought that the version_found=false part in the logs insinuate that something is wrong with the version information in the request. However, if I change it to something that does not exist I get the following response:

“This API version does not seem to exist”

Any clues?

2

Hi Rob,

Could you please provide the target URL that you used to access your API?

Kind regards,
Jess @ Tyk

3

The URL is identical to the one used before the API was versioned (where the request is working) since the version information is based in the header. It’s something like https://some-name.com/drowsy/helloworld

4

Hi Rob,

Can you please confirm, did you create a new policy for this version and then also update the JWT policy field or did you simply update the existing policy?

Kind regards,
Jess @ Tyk

5

I tried both, updating an existing policy and creating a new policy. The result is the same.

6

Any hints where to start debugging?

7

The API Key provided here is the internal representation of the JWT within Tyk, if you look up this token in your dashboard, you will see the access rights that have been set as well as whether or not the policy is set on the token, could you take a look to see if they match up to the policy?

8

Actually, I think I just managed to replicate the issue, the JWT key name is case sensitive, so if you have it set as PID in your JWT and pid in Tyk as the policy source then the error you describe appears (because Tyk can’t find the key in the JWT claims, it can;t locate the policy).

On a different note, running theough your scenario with the correctly cased claim names has the versioning work just fine :slight_smile:

9

I think I found the issue, pointing me to the internal storage was a very good hint. So what I did to test this was to issue myself a very long running JWT. I used the exact same token for the unversioned API as well as for the next test with the same API which was then versioned (which then results in: “Access to this API has been disallowed”). When I looked up the key from the internal storage I saw that it had the Default version of the API as granted access although the permissions of the policy have been changed such that they grant access to v1 and v2 and Default does not exist anymore.

When I issued myself a new JWT, i.e. different principal (sub field), and sent a request again the access worked. My guess is that the access rights are not evaluated again if the same principal is seen multiple times?

10

Actually the policy should still apply the new version data, but it will only happen when the token is used (that’s when the policy data is evaluated), so it’s a bit odd that it isn’t working for you when it worked for my test environment.