Azure API Management policies allow you to change how your APIs function and behave. Typical examples include rate-limiting responses, converting one format to another, such as XML to JSON, or even modifying the contents of the data returned.
Azure API Management offers a range of built-in policies, or you can create custom ones.
The following are some examples of use cases and policies:
- Restrict who can access your APIs by specifying allowed IP ranges (whitelisting) or denied IP ranges (blacklisting).
- Set rate limits on calls to prevent too much data from being sent in one call, or limit how many times an API can be called. This can help protect you from hackers or consumers who have called the API incorrectly.
- Check HTTP headers to ensure they contain specific values. For example, ensure all requests include the authorization header.
- Create mock responses. Ideal for testing, an API policy can prevent the call from returning real data and supply mock data instead.
- Transform data from XML to JSON, which is especially useful if you expose older XML APIs and need a consistent data format returned to your consumers.
- Override data in the HTTP headers to add or remove information. A standard security requirement is to not expose data in the HTTP header that might provide hackers with the information they can use, such as the X-Powered-By or Server headers.
- Override content data. Suppose an API returns content you don’t want it to, rather than modifying the API (which may need to supply the data for internal systems). In that case, you can overwrite that information using a find-and-replace statement.
- Allow Cross-Origin Resource Sharing (CORS). You can use a policy to override an API’s native CORS ability by adding the allow origins and allowing HTTP header methods.
Using API policies is a powerful tool for many transformations and security-related tasks without updating the source APIs, modifying behavior for internal or external calls only.
When exposing your APIs to consumers, you may want to control who has access. This control is sometimes required when developing the API itself. However, if you have multiple APIs, or if those APIs were initially built for internal use, access control mechanisms may not have been built into them.
Using Azure API Gateway, you can restrict access to all your APIs without writing any additional code. When securing APIs, you have three options – subscription keys, client certificates, or authentication.
Securing your APIs with subscription keys
By default, when you import APIs into an Azure API gateway, subscriptionkeys are required. A subscription key is an alpha-numeric key generated for you and must be supplied with every request.
Subscription keys can be scoped to all APIs, a single API, or a product, which is a collection of one or more APIs.
When your consumers request one of your APIs, the key must then be included in a header as an Ocp-Apim-Subscription-Key key or as part of a query string using the subscription-key parameter. Both the key and parameter names can be changed if required.
Each subscription has two keys – a primary and a secondary key. Having two keys helps prevent downtime if you need to regenerate a key. For example, you could regenerate the secondary key and transition consumers over to the new key before regenerating the primary.
Leave a Reply