API Management and architecture deployment

API Management architecture and deployment is important for customers and their API journey. Moving forward to determine the path for a successful, scalable, and secure deployment of API Management solution is key in this deployment.

API Management and architecture deployment

An API Management solution consists of three critical components.

1. API Gateway
2. API Manager
3. API Developer Portal

API Gateway is the runtime component responsible for processing the real-time API traffic from consuming applications like single-page applications (SPA), mobile applications, websites, business systems, IoT devices, etc.

The most important responsibility of an API Gateway to secure your APIs or backend services. The security policies defined to protect an API can be enforced at multiple levels, namely:

1. Surface level
2. Global level
3. Service level
4. Method level

“Surface level” security is usually enforced by Web Application Firewall (WAF) to block SQL Injection, cross-site scripting, bot attacks, etc. In the case of Axway’s API Management solution, our API Gateway includes apache’s mod security engine (open-source WAF).

“Global level” security can be enforced within the API Gateway in an API agnostic and consumer application-agnostic fashion. When I say agnostic, what I mean is that an incoming API request should go through generic checks irrespective of who is making the API call and which API is being invoked. Most common generic checks I have helped few customers enforce are

1. HTTP Verb whitelisting: Only allows the HTTP verbs that are used in your backend API ecosystem. Most whitelisted verbs can be GET, POST, PUT, DELETE, OPTIONS, HEAD.
2. Security context: A security token is expected to be associated with the incoming API request. The security token can be an API Key in the HTTP header, Bearer token passed as HTTP Authorization header, client certificate (two-way SSL), HTTP Basic credentials, etc.
3. Content-Type whitelisting: Only allow a specific set of content types like application/json, text/xml, MIME, etc.
4. Message size: Enforce a minimum and maximum limit to the size of the incoming request (includes headers, payload, and attachments).
5. Scanning: If the incoming request has an attachment(s), scan the attachments against anti-virus servers like McAfee. In the case of Axway API Gateway, we provide the ability to integrate with an anti-virus server that can support ICAP.
6. Certificate Validation: If your APIs are secured using two-way SSL, make sure the client certificate passed in the incoming request is issued by a trusted Certificate Authority, the certificate is not expired and revoked.

“Service level” security, as the name suggests, is enforced by determining the API being called and the associated security token expected in the request. For example, if you secure an API using OAuth 2.0, API Gateway expects the bearer access token in the Authorization header.

Once the access token is found, API Gateway can validate the token (making sure it is not expired), identify the consumer application associated with the token, and check the application’s service entitlements.

If you define application quota, API Gateway will make sure that the application is not exceeding the pre-defined threshold (rate-limiting) for a specific API.

“Method level” security enforcement is critical when you consider customers in Healthcare, financial, and other sectors that are compliance savvy (HIPAA, PCI/PII, SOX, etc.).

For example, the incoming request has customers SSN in an encrypted format. API Gateway can retrieve the encrypted value, decrypt it, make sure the provided value meets a specific regular expression (XXX-XX-XXXX).

A common question that comes up often is “Where should I deploy the API Gateways to enforce the security levels outlined above?” Are the gateways going to be deployed in the demilitarized zone (DMZ) or behind the internal firewall in INTRANET?

Or should they be deployed in a public cloud-like AWS, Azure, etc.? The answer depends on where the APIs and the consuming applications reside. Few principles we established upfront are outlined below.

1. An API request for consuming applications will always go through API Gateway. It does not matter if the application resides in the INTRANET (in the same network as API), in the demilitarized zone (DMZ) or the cloud (mobile, partner, etc.). In other words, no backdoor access should be allowed to consumer APIs.
2. Appropriate network rules (VLAN) should be defined and enforced so that API Gateways are the only systems allowed to reach the APIs. If a consumer application manages to get hold of the backend API URL and try to invoke it, underlying network rules should block the access and result in resource unreachable error.
3. Keep the network latency low as much as possible. For example, if an internal consumer application and API resides on the same network (say INTRANET), it does not make sense for the application to traverse into DMZ or cloud to go through API Gateway and eventually come back into INTRANET to consume API.

Based on the above three principles, I have depicted the architecture blueprint implemented by many customers.

Slight variation

A slight variation of the above architecture is depicted below. In this scenario, API Gateways are deployed in both DMZ and INTRANET. API Gateways in DMZ often serve as a light-weight proxy mainly to enforce surface, global, or both level security policies.

API Gateways in INTRANET mainly enforce service-level and method-level security policies. Some of our customers do leverage Web Application Firewall in DMZ to enforce surface-level security and delegate the global-level, service-level, and method-level security enforcement to API Gateways in INTRANET.

This is a perfectly valid architecture and highly recommended. The bottom line is any application, irrespective of where it resides, will go through API Gateway to reach the backend API.

Some of you reading this article might have a question: “What if an API wants to call a different API?”. Does this scenario require API #1 to go through API Gateway to reach API #2? Not necessarily!

If we are talking about “east-west” traffic (service intercommunication), there are alternate solutions like service mesh that are apt.

The API Gateway discussed in this article is mainly intended for “north-south” traffic, i.e. from consuming applications to backend APIs.

In the “north-south” scenario, the key goal of the API Gateway is to not only secure the API but also abstract its presence from the calling application. “Abstraction” and “Security” are the two most important aspects of API Gateway.

Everything else like data conversions (XML to JSON), orchestrations (building façade APIs) are added benefits.

I intentionally kept this article on API Management architecture and deployment simple. If you have any questions or would like to have deep dive whiteboarding sessions, please feel free to connect with me on LinkedIn, I will be happy to help you.