Keys have access to all the APIs sharing the same policy

Support
1

Hi,

I have several APIs with the quote and rate limit controlled by the same policy. When I create a Key for a specific API I can use that key to make calls to other APIs and It should happen. When there is one policy controlling several APIs the keys can be used in all the APIs?

2

That’s correct. The security policy acts as an ACL (and other things such as rate limits and quota counters) for one or more APIs.

So if a key references a security policy, it will inherit the Permissions defined in the policy.

3

So for example, if I have these 2 APIs controlled by the free_plan policy it means that if I generate a Key for API1 I’ll be able to use it in API2 ?

{
  "free_plan": {
      "rate": 10,
      "per": 1,
      "quota_max": 1000,
      "quota_renewal_rate": 60,
      "access_rights": {
        "11111111": {
          "api_name": "api1",
          "api_id": "11111111",
          "versions": [
            "Default"
          ]
        },
        "22222222": {
          "api_name": "api2",
          "api_id": "22222222",
          "versions": [
            "Default"
          ]
        }
      },
      "hmac_enabled": false
  },
4

Also, when I make request with Key1 belonging to API1 it will decrease the counters of API1 or also from API2 ?

5

Not technically. If you create a key for API1 then that key is bound to API1. API2 cannot use the same key.

However, if you create a key for the policy “free_plan”, then that key is bound to any APIs on the policy. Creating a key for a policy should is something like this.

{
    "apply_policies": ["free_api"],
    "allowance": 100,
    "rate": 100,
    "per": 5,
    "expires": 0,
    "quota_max": 100,
    "quota_renewal_rate": 60

}

You can read more about Applying a policy to a key (tyk.io)

6

Hi @Olu thanks for your answer.

Precisely that’s the behaviour I don’t want. I want Keys from API1 only allowed to make request to API1 and Keys from API2 only allowed to make requests to API2. The issue I’m facing is that when I have a policy controlling several APIs then the key can be used for all the APIs (and that’s the behaviour I don’t want). So It seems that I can’t use policies.

7

You can try to create a policy granting access to api 1 and another policy granting access to api 2? Does that not work for you? If not, really interested to understand your use case.

8

Hi @ahmet but in that case if I have to create one policy per API there is no point in using policies, I better set the rate limit and quota directly in the API definition.

9

Setting the rate limit and quota in the api def is to protect the upstream. No matter how may keys with individual rate limits there are, the overall rate cannot exceed the api definition limits.

By creating a policy, you can issue api keys and change their limits and quotas and access control without having to modify the key.

Also, if you issue 500 keys, you can change every key permissions by modifying one policy.

10

If I don’t use policies and I just use the API definition to set the quota and the rate limit and I issue 100 keys and then let’s say I want to increase the rate limit and quota for all the keys belonging to that API. Is not enough to change the quota and rate limit for the API and the keys belonging to that API will get this new limits ?

I’m not using the Keys to set the quota and rate limit, I leave that to the API definition, and that’s why even I’m not using policies I think that I don’t have to modify the key, or I do have to modify it ?

12

This is possible and may be suitable for your use case. Consider that misuse of a single key might consume all the available rate for the api and deny service for other keys. Is this suitable for you?

13

Yes because I’m creating a new API (with same domain) for every customer of the API service, the boundary for every customer is their own API definition, so if they consume all the quota its their own quota. In your experience is that a crazy idea ?