How to have the same key access multiple APIs

Support Installation and Deployment
1

We have about 18 services and 174 endpoints. These are grouped into 24 standard products (RO and RW). Developers are given access to some combination of standard products and occasionally special products for use in their application under one api key each for testing and production.

I don’t see how I can implement this in Tyk. It appears that at best I can create a policy for each product, which is then a Tyk Catalog item, but that a developer’s application would need many API keys.

Is there any way to assign the same api key to access multiple policies, either through the portal, dashboard, or some apis?

Also, all of the above standard products are generated from vendor specific tags in the swagger file. Is there an API to create catalog items?

2

Hi @gwshaw,

Have you tried manually adding more than one API to the Access Rights when creating a new key in the Dashboard? I think creating a key with these settings could help in this case.

Kind regards,
Jess @ Tyk

3

I do that now. The problem is, for instance, an app supplying movies information will access endpoints allowed for the Centre Product (select endpoints with data about centres, encompassing several APIs) and the Movie Product (data about showtimes in one API). In the Tyk architecture this is also two catalog entries and also two keys.

With the number of endpoints we have, defining all the useful combinations to have only one key will be unwieldy. Developers don’t want to deal with lots of keys.

One solution is to develop our own portal that creates a policy for each developer application and have our Product list be outside of the Tyk (don’t use the Tyk portal or API Catalog). Unfortunately, an evaluation criteria for selecting a gateway is the total amount of work to make it operational. Would having hundreds or thousands of policies affect the performance of Tyk?

4

There might be a way to do this with the portal, but it means still having some custom code.

  1. Crete a dummy API that is closed using the token method
  2. Create a policy called “Portal Devs” that grants access to this API and has a rate limit and quota that you want for all your self-signed up devs
  3. In the policy editor, make sure that the node is segmented, and that it is only enforcing the rate limit and the quota, NOT the ACL
  4. In the portal settings screen, add a key request hand-off URL to a custom application, this application will offer the product list functionality and handle the final key modification before it goes to the user.
  5. Publish this policy to the portal as a single catalogue entry

Now the flow is:

  1. User signs up
  2. User selects catalogue entry to get access to APIs
  3. User is redirected to your custom application where they select the APIs they want access to, this redirect includes the key request ID
  4. Custom app approves the key request using the REST API
  5. Tyk Gateway generates a token based on the policy, granting access to the dummy API and setting the relevant quotas and rate limits
  6. Tyk Gateway returns API token to your app
  7. Your app uses the dashboard REST API to modify the ACL of this token to include all the relevant APIs that the user wants access to and updates it
  8. Your app gives the user the token

Because policies are “copied” into tokens when they get used, and the policy we used as a template for the portal does not ernforce the ACL, it means that when the developer uses the token, the policy tags, rate limit and quota will be enforced on the token, but the ACL will not be copied and instead fall back to the one that you have set when you modified it in your product app.

This means you have one policy (or multiple tiers if you are selling access on a resource basis) but you can limit / segment access elsewhere, while having Tyk continue to track the developer, their usage, their tiers and control access to the services by revoking the key from Tyk.

It does mean more work on your side, but less than generating thousands of policies.

(Tyk would be fine with thousands of policies, but it would become a management nightmare).

5

Martin:
Thanks. I don’t see how to:
7. Your app uses the dashboard REST API to modify the ACL of this token to include all the relevant APIs that the user wants access to and updates it

The only token APIs I see are:
https://tyk.io/tyk-documentation/tyk-rest-api/token-management/
and
https://tyk.io/tyk-documentation/tyk-dashboard-api/api-tokens/

I don’t see where the ACL would be changed.

6

You can use the dashboard token API:

GET http://dashboard:3000//api/apis/{api-id}}/keys/{key-id}

This will return a token session object, in this case, the one created by the gateway, for the PAI ID you can use your dummy API.

Modify the session object to include your API, see the access_rights section here is the thing that needs to be extended to include the selections made by the developer:

{
    "api_model": {},
    "key_id": "54b53d3aeba6db5c3500000289a8fbc2bbba4ebc4934bb113588c792",
    "data": {
        "last_check": 1421674410,
        "allowance": 1000,
        "rate": 1000,
        "per": 60,
        "expires": 1423684135,
        "quota_max": -1,
        "quota_renews": 1421164189,
        "quota_remaining": -1,
        "quota_renewal_rate": 60,
        "access_rights": {
            "39d2c98be05c424371c600bd8b3e2242": {
                "api_name": "Nitrous Test",
                "api_id": "39d2c98be05c424371c600bd8b3e2242",
                "versions": [
                    "Default"
                ]
            }
        }
    }
}

And then:

PUT http://dashboard:3000//api/apis/{api-id}}/keys/{key-id}

{session data}

Again, include the dummy API as the api-id section.

7

Ok, so you are telling me that I can include

          "allowed_urls": [
            {
              "methods": [
                "GET",
              ],
              "url": "/some_resources"
            },
            {
              "methods": [
                "POST"
              ],
              "url": "/some_resource/(.*)"
            },
          ],

in the access_right section, though allowed_urls is not documented. Correct?

Since the issue here and in many other posts here is lacking or incorrect documentation, may I suggest that instead of just answering the questions here that you, as the best source of knowledge, update the documentation and then post a link to the corrected page.

Thanks!

8

Now why didn’t we think of that? :slight_smile: Thanks for letting us know, because we had never thought of working on our docs by ourselves.

FWIW, We do update the documentation when we see things missing and are reactive to the requirements of our community, snide remarks notwithstanding.

To answer your question: Yes, allowed_urls is possible in the token object, but it is mainly a policies feature - which is why it is documented with policies.

9

I am trying to explore tyk. What i want is access limit based on method and url pattern per JWT token. I am not using dashboard. Just manual configuration. My policy configuration is

{
“default”:{
“rate”:1000,
“per”:1,
“quota_max”:100,
“quota_renewal_rate”:60,
“access_rights”:{
“12345”:{
“allowed_urls”:[
{
“methods”:[
“GET”
],
“url”:"/api/users"
},
{
“methods”:[
“POST”
],
“url”:"/api/"
}
],
“api_name”:“My API”,
“api_id”:“12345”,
“versions”:[
“Default”
]
}
},
“org_id”:"",
“hmac_enabled”:false,
“active”:true,
“is_inactive”:false
}
}

Listen path for 12345 application id is /test-tyk/.

Issues I face:

Invalid Policy:

I am creating a JWT token with policy as “user1” which is not defined.

  1. All URL can be accessed via this JWT. Is there something wrong?

Valid Policy:

I am creating a valid JWT token with policy as “default”.

  1. When access URL GET http:/ip:port/test-tyk/users/status. I am able to access but in GET allowed URL the path is defined as /api/users. Is there something wrong?

  2. There is no allowed URL map for verb PATCH but i am still able to access PATCH API’s.

Any suggestion would be helpful.

10

You must use the numeric policy ID, not the name, otherwise the Policy will not be found.

11

@jess

https://tyk.io/docs/tyk-v2-2-documentation-components/tutorial-create-a-policy-ce/

I am following the above URL to create file based policy. How to I get the policy ID is this?

12

Hi @sairam866,

Apologies for the confusion earlier, if you’re using the Community Edition, the use of alphanumeric policy IDs is permitted so the IDs you were using before would have been valid (this is not the case if you are using the Dashboard or its API mind, which does require a numeric ID). Could you please attach your API settings either to this ticket or to the other ticket you raised for this issue? You should be able to do this by making a GET request to /tyk/apis/{{api-id}} and copy and pasting the response.

Kind regards,
Jess @ Tyk

1 Like