If you are already familiar with the WSO2 API Manager you would know that the API Manager provides the capability to apply throttling tiers to an exposed API. A throttling tier is an access limit which is applied to a given API subscription to make sure that API’s are not used over and above the expected level. WSO2 API Manager’s subscription plan is such that an API Subscriber can choose from a set of throttling tiers available to him when subscribing for an API. By default all the throttling tiers are available for all users.
In real world an organization would want to have control over how users can subscribe and access their API’s. Opening up all the tiers to all users may not be acceptable. In order to address this concern API Manager provides a capability to assign roles to different throttling tiers hence only users belonging to a given role would have access to that particular throttling tier. Lets take the following example. You would have multiple user groups such as internal developers, registered external partners, and guest external partners. You would want to open up your API’s for these users but want to have different plans to these users. For this example we will only be dealing with the existing throttling tiers, based on this I will create the following mapping of user roles to tiers.
Bronze Tier - No Restriction
Silver Tier - All users expect guest external partners
Gold Tier - Only Internal developers and Admin users
Unlimited - Only Admin users
These restrictions can be created from the API Publisher’s user interface. In order to do this, login into the Publisher console as a API Publisher. Once you are logged in you will see the ‘Tier Permissions’ link on the left hand navigation panel. Click on the this link. Once you are in the Tier Permission page set the roles to which you need to ‘Allow’ or ‘Deny’ to a given throttling tier.
You can Create your own throttling tiers  and then define how these tiers should be made available to different application developers using the Tier Permission option provided available in the API Publisher.
XACML is a powerful access control policy language implemented in XML that can provide a standardized way of validating authorization requests. XACML is the de-facto standard for authorization and provides the ability for a 3rd party application/component to enforce attribute based access control.
Given below is a reference architecture on how different XACML components can work in the deployment.
Policy Enforcement Point (PEP) – PEP is a component that would enforce access control to a resource based on the input received from a Policy Decision Point (PDP). In the actual deployment PEP can be an application that would provide access to a resource. PEP would send attributes to the PDP and the PDP would reply back with response that would be either to allow or deny access to a resource.
Policy Decision Point (PDP) – PDP is the XACML engine that makes policy decisions on behalf of an enforcement point. PDP would make policy decisions based on a set of XACML polices that are deployed in the PDP.
Policy Information Point (PIP) – PIP is an information source to which PDP can refer to and get more information on an attribute. PIP can be a user store, a flat file, a DB or any data source. For example if the PDP receives a username as an attribute, it can refer to a user store and get the set of roles assigned to that particular role to make a decision on whether to deny or grant access to a resource.
Policy Administration Point (PAP) – PAP is a component from which XACML policies are created/uploaded, edited and deployed to a PDP. An authorized user can come and create these policies in the PAP and the required policies can be deployed to the PDP.
Policy Repository – Policy Repository is where all the XACML policies are stored, policy repository can also manage multiple versions of a XACML policy.
When exposing API’s for consumption it is of paramount importance that the API access is controlled so that service consumers are not able to misuse these exposed API’s. WSO2 API Manager provides the capability to throttle API’s that are exposed via the API Manager. API Manager allows throttling at multiple levels.
1. Application Level throttling
2. API Level throttling
3. Resource level throttling
To understand the above levels of throttling we need to first understand the concept of API’s and applications in the API Manager.
An application inside the WSO2 API Manager is a logical group to which API’s are subscribed into. For example if you take a Weather Application, this will have 2 API calls. First one would make a call to a Location API to get GPS coordinates of the current location, after which a second API call would be made to a Weather API to get weather information of the current coordinates.So in this case the Application within the API Manager would be the ‘Weather Application’ and both the Location API and the Weather API would be subscribed under this application. This can be illustrated in the diagram below
Lets related the above diagram to different throttling tiers that are available with the API Manager, this can be illustrated as below.
1. Application Level Throttling
Each application can have a throttling policy defined that would limit the aggregated number of API calls that can be made to API’s subscribed under that application. In this case we can throttle the number of API calls made from the weather application irrespective of whether they are calling the Location or the Weather API. A throttling tier can be associated to an application from API Store. This can be done by navigating to ‘My application’ tab as shown below.
2. API Level Throttling
Each API can be associated with a throttling tier. When an API is subscribed the subscriber would have a choice to choose which throttling plan to subscribe. This is shown in the screenshot below
The choice of throttling plans that needs to be associated to an API can be selected at the point of API creation. Given below is a screenshot which shows how to add a throttling plan to an API.
3. Resource Level Throttling
WSO2 API Manager also allows you to define throttling tiers for each resource within an API. This allows you to have more control on how each resource is throttled in a given API. In the above example the Weather API would have two resources ‘getWeather’ and ‘getFullWeather’ which can have two different throttling tiers. A throttling tier can be associated to a resource at the point of API creation. This is shown in the screenshot below.
If you wondering on how to set these tiers that you see on the screen, you can refer to the following API Manager documentation