Any plans to support associating multiple policies with an account?


We discussed this briefly via email.

We find ourselves in a situation where we’re forced to choose between setting up permutations of access resulting in a largish number of policies, and managing access in a large number of keys individually. Neither is particularly appealing; the latter less so, because it makes both setting up new keys and using versioning impractical. The former is challenging because our business unit has chosen a cafeteria model for sales, and to support this with policies is an n!-complexity problem.

Are there any plans to support policy composition? Is it a difficult problem to solve correctly in Tyk? What could we do to support implementation of such a feature?



Hi Sean,

I see, yes this could be a problem. I think in order to see if there’s a feasible solution we need to look at a real use case…

For example, A policy can control multiple facets:

  • Quota
  • Rate limit
  • Access control (API & Version)

I’m assuming you would want to have a class of policies that sets rate limits and then another class of policies that sets access control. Or, more complex: Class 1: Quotas, Class 2: Rate Limit and Class 3: Access Control.

Then when a token appears and it’s metadata is read, we detect a list of policies instead of a single policy, with each policy selectively enforcing a class, in turn, composing the access rules for the token itself.

In terms of implementation, there would need to be some changes, we would need to add a new field to the token data:

  • appliy_policies []Policy

Then modify the policy object to have a few bools:

PolicyIsPartitioned bool
Partitions: struct {
    Quota     bool
    RateLimit bool
    Acl       bool

We can then have the policy enforcement method only apply the partitions that are enabled in the policy, that way you could have combinatorial policies (and they can be in any order).

So yes, totally doable, and actually a good idea because it increases the effectiveness of policies, since you can then create policies that are either all-in-ones, or are combinatorial.

Getting this into the gateway is pretty straightforward, adding it to the dashboard and portal will take a bit longer though :slight_smile:

I’ll put it on the roadmap, because even in a partial implementation it could be very valuable.


Hi Martin,

Thanks for the response, and that’s encouraging. Having different policies to cover areas of concern is a good case; in our use case, we’d want to mix API sets.

Say we sell access to flight, train, taxi, bus, and sub-orbital slingshot (schedules and fees). Each mode of transport has it’s own API, and our customers can buy any combination of them. We’d have to support 31 policies for every possible combination of API set customers might purchase.

We’d love to see a policy union algorithm; the ACLs finally applied to a token would be a union of the API set defined for all policies associated with the account. Client Megacorp Inc., who provides sub-orbital slingshot travel for their executives and rail travel for everybody else would have the Rail and Slingshot policies associated with their account.

If it matters, access through the API is more useful than access through the web interface. But we appreciate even the consideration of inclusion of this feature request.



That does seem a bit trickier, our preferred approach would be to keep things as simple as possible, and in this case I think access control lists that have such high complexity should be pushed down to the token layer so that:

  1. A policy can control the quota, the rate limit or the ACL or any combination thereof depending on its partitions
  2. These partial policies cannot be used in the developer portal

That way, if users require custom ACLs then that can be customised per-token while the policy will only overwrite the partitions it has set.

In fact, in terms of development the first step would be just to enable policies to be partitioned, and when applied fall back to the underlying token behaviour where there is a gap. It would still be one policy per token, but those policies can leave the ACL up to the token generator.

The second step would be to make them combinatorial where quota, rate limit and ACL are applied separately by three different policies.

This gives us a good graduation in terms of features and makes It simpler to get to market, it also means your particular issue can be solved by making tokens the holder of the ACL which removes the number of policies that need to be created altogether since it’s set on a per client basis.



Congratulations for your great software!

Is there any roadmap date for this feature?
Class 1: Quotas, Class 2: Rate Limit and Class 3: Access Control

Will this work with JWT tokens?



The partitioned policies were the first step for this feature, multi-policies is the next step, it will most likely be in v2.4 though as v2.3 is currently in final testing / RC stage.



Thanks for your quick answer


Hi Martin,

Would you be willing to forecast when you think v2.4 might be out? Which quarter, which year?

We just realized (stupidly, it took me this long) that we can’t solve the problem with policy permutation because we have different rate limits for different APIs based on back-end load capacity. The only solution I see is to create multiple tokens for each client, for each API they have access to.



Hi Sean,

We’re currently integration testing v2.3, we’re expecting to have that version released in the next 3-6 weeks, we’all then start working towards combinatorial policies, it might go into a point release after v2.3 is out.

Sorry it’s taking so long, but there’s a lot going into v2.3!



Hi Martin,

Thanks – first, congratulations on 2.3! We just saw the announcement… very exciting, and we’re glad to see it.

I was trying to get a feel for the frequency between releases. Not a specific date, but a general feel for how long we might be looking at. I was looking at the “releases” forum for a pattern but didn’t see one.

Can you talk a little more about the implementation? I’m curious about how this will look, and what it might afford us. A sort of multiple inheritance model? Would we be able to use this to apply different rate limits per API on a single token?




Hi Sean,

Thanks :slight_smile: We tend to “release when it’s ready” between bigger changes, and within minor versions we release many patches very quickly.

But usually the release cadence is betwen 3 and 6 months depending on what is planned.

With regards to this policy update, we have now added the semented policy support, and the next step will be to have multiple policies attached to a token. This way, each policy can represent a partition: rate limit, ACL, quota and be combined to provide a “whole” policy.

The complexity here is that this will need to be extended into the portal so that portal entries also support policy groups.

It should be quite straightforward to work with. For now, we’ll extend out the partition model. After that we will start looking at more specific policies on a per-api-basis.

Hope that helps!


That’s perfect, thank you.