Securing the API Economy
An API management market has created new architecture patterns to secure the API economy. Why? Because today’s application program interfaces (APIs) are not your father’s APIs. Once, APIs primarily linked modules of code on the same computer. Once, code could be designed without the overhanging fear of automated vulnerability discovery and exploit. Those days are gone and the trust boundaries imploded.
Source: 3Scale
APIs have become interfaces to expose massively distributed applications and systems across functional, organizational and national domains. Online business and IT architects must address APIs as a core element of their projects. And in considering APIs, they must be aware of the tradeoff between usability, scale and security shown in the diagram above.
Behind every killer app these days there’s an API. APIs have become so important that a new term – “API Economy” – has come in vogue. My definition:
As a book I’ve read called “APIs: A Strategy Guide (pdf)” notes, APIs are big business. Too big to be left to random development projects, or even just to the technologists. Deploying a killer API can take a major product marketing campaign. Getting the API architecture technically right is also critical. References on technical API best practices are a bit fragmented by the type of APIs around, but browsing the apievangelist.com and programmable web sites is a good start to get the big picture.
Considering the complexity of WS-*its pretty easy to call the shift to REST a return to usability. Unfortunately, whereas WS-* may have built in too much security, REST like HTTP and the internet itself built in too little. I ended up writing a series of posts starting with REST Uneasy: Do we Need to Worry about OAuth 2.0? (And the answer was “Yes.”) Perhaps we could define this as an axiom of the API economy:
As easy APIs enabling accelerated online services and cloud computing growth emerged, so did cyber-attacks waged directly against them (such as cross site scripting or DDOS exploits) and flanking attacks (such as this OAuth breach of Facebook and Twitter user accounts)
But security often conflicts with usability. Most developers still use simple ‘API keys’ to provide their services. Many know that they should be using more robust or standardized techniques such as split API keys or OAuth 2.0-based flows. Anecdotally, however, according to Mark Cheshire, COO for 3Scale, an API management company: “About 50% of our customers want to implement OAuth 2.0, but many are put off by the complexity of the protocol’s many choices. Only about 20% actually implement it in the end. We’re all working to increase that number.”
API Management Market
Whatever the protocol, API usability, security and scale don’t happen by themselves, at least not when large numbers of organizations and developers get involved. A market for API management began to grow from two groups of vendors emerging roughly in parallel:
- Layer 7, Vordel, SOA Software and Sonoa Software began catering to the enterprise market in the mid-2000s with XML security gateways and/or web services management solutions.
- On the demand side, a plethora of dynamic web services and online sites emerged from Web 2.0 asynchronous Javascript (AJAX) deployments, RESTful applications and the rise of cloud computing. Almost of all vendors in the space began to converge on API management and to broaden their solution to cover usability and scalability as well as security and management.
The market really began to heat up in the last few years with the acquisitions of Layer7 by CA, Mashery by Intel, and Vordel by Axway.
API Management and Security Architecture
To protect APIs, vendors typically use a classic security policy management pattern:
- Policy enforcement point (PEP): An intermediate node on the network (such as a proxy) where network traffic from the API is intercepted in real time so that it can be monitored and filtered for compliance with policy. API calls can be blocked, transformed or instrumented at the PEP.
- Policy decision point (PDP): Often a central server(s), or cloud-based service that makes policy decisions in real time on behalf of many “dumb” PEPs. The PDP could implement OAuth authorization server functionality, or X.509 certificate checking, for example.
- Policy management point (PMP): Generally an offline component that defines the technical policies for control and feedback in the network of PDPs and PEPs. Access control rules definition and key management may fall into the PMP’s purview.
A single API management infrastructure can implement this policy pattern on many different APIs at once. The infrastructure generally aims to make API security more usable by taking some of the protocol, registration, verification and management burdens off the services and putting them into the policy infrastructure.
That’s why it’s important when deploying API-based infrastructure and API management tools to choose the right architecture. Cheshire explained that his company supports three patterns for the PEP deployment:
- An agent co-located with the application service endpoints
- A proxy, or gateway
- In general, the agent approach is appropriate when API services are concentrated on just a few endpoints that your organization controls whereas the proxy service is appropriate when dealing with many heterogeneous endpoints.
Bottom line
It’s important when deploying new online services to factor the right balance in up front for security, usability and scale of APIs. Considering the tradeoffs between all three values along with the appropriate role for API management can help organizations architect a balanced solution to win in the API economy.
Related reading