API management – Infrastructure VS SaaS

February 7, 2012

The Enterprise is buzzing with API initiatives these days. APIs not only serve mobile applications, they are increasingly redefining how the enterprise does B2B and integration in general. API management as a category follows different models. On one hand, certain technology vendors offer specialized infrastructure to handle the many aspects of API management. On the other, an increasing number of SaaS vendors offer a service which you subscribe to, providing a pre-installed, hosted, basic API management system. Hybrid models are emerging, but that’s a topic for a future post.

Before opting for a pure SaaS-based API management solution offering, consider these below.

The Cloud Advantage
One can realize the benefits of cloud computing from an API management solution without losing the ability to control its underlying infrastructure. For example, IaaS solutions let you host your own API management infrastructure. Private clouds are also ideal to host API management infrastructure and provide the added benefit of running ‘closer’ to key enterprise it assets. Through any of these SaaS alternatives, an API management infrastructure optimizes computing resources utilization. IaaS and private cloud based API management infrastructure also provide elasticity and can scale on-demand. Look for API management solutions that offer a virtual appliance form factor to maximize the benefits of cloud.

Return on investment
The advantage of a lower initial investment from SaaS delivered API management solutions quickly becomes irrelevant when the ongoing cost of a per-hit billing structure increases exponentially. With your own API management infrastructure in place, you leverage an initial investment over as many APIs as you want to deliver, no matter how popular the APIs become. Many early adopters, which originally opted for the SaaS model, (notably the more successful APIs) are currently making the switch to the infrastructure model in order to remedy a monthly cost that has grown to unmanageable levels. Unfortunately, such transitions are sometimes proving more costly than any initial costs savings.

Agility, Integration
SaaS solutions provide easy-to-use system isolated in their own silo. This isolation from the rest of your enterprise IT assets creates a challenge when you attempt to integrate the API management solution with other key systems. Do you have an existing web portal? How about existing identity, business intelligence, billing systems? If your API management solution is infrastructure based, you have access to all the low level controls and tooling that are required to integrate all these systems together. Integrating your API management with existing identity infrastructure can be important to achieve runtime access control. Integrating with billing systems is crucial to monetize your APIs. Feeding metrics from an API management infrastructure into an existing BI infrastructure provides better visibility, etc.

Security
Depending on the audience for your APIs, various regulations and security standards may apply. Sensitive information travelling through a SaaS is outside of your control. Are any of your APIs potentially dealing with cardholder information? Does PCI-DSS certification matter? If so, a SaaS-based API management solution is likely to be problematic. In addition to the off-premise security issue, SaaS based API management solutions offer limited security and access control options. For example, the ability to decide which versions of OAuth you choose to implement matters if you need to cater to a specific breed of developers.

Performance
Detours increase latency. By routing API traffic through a hosted system before getting to the source of the data, you introduce detours. By contrast, if you architect an API management infrastructure in such a way that the runtime controls happen in direct path of transaction, you minimize latencies. For example, using the infrastructure approach, you can deploy everything in a DMZ. Also, by owning the infrastructure, you have complete control over the computing resources allocated to it.


RESTful Web services and signatures

October 2, 2010

A common question relating to REST security is whether or not one can achieve message level integrity in the context of a RESTful web service exchange. Security at the message level (as opposed to transport level security such as HTTPS) presents a number of advantages and is essential for achieving a number of advanced security related goals.

When faced with the question of how to achieve message level integrity in REST, the typical reaction of an architect with a WS-* background is to incorporate an XML digital signature in the payload. Technically, including an XML dSig inside a REST payload is certainly possible. After all, XML dSig can be used independently of WS-Security. However there are a number of reasons why this approach is awkward. First, REST is not bound to XML. XML signatures only sign XML, not JSON, and other content types popular with RESTful web services. Also, it is practical to separate the signatures from the payload. This is why WS-Security defines signatures located in SOAP headers as opposed to using enveloped signatures. And most importantly, a REST ‘payload’ by itself has limited meaning without its associated network level entities such as the HTTP verb and the HTTP URI. This is a fundamental difference between REST and WS-*, let me explain further.

Below, I illustrate a REST message and a WS-* (SOAP) message. Notice how the SOAP messages has it’s own SOAP headers in addition to transport level headers such as HTTP headers.

The reason is simple: WS-* specifications go out of their way to be transport independent. You can take a soap message and send it over HTTP, FTP, SMTP, JMS, whatever. The ‘W’ in WS-* does stand for ‘Web’ but this etymology does not reflect today’s reality.

In WS-*, the SOAP envelope can be isolated. All the necessary information needed is in there including the action. In REST, you cannot separate the payload from the HTTP verb because this is what defines the action. You can’t separate the payload from the HTTP URI either because this defines the resource which is being acted upon.

Any signature based integrity mechanism for REST needs to have the signature not only cover the payload but also cover those HTTP URIs and HTTP verbs as well. And since you can’t separate the payload from those HTTP entities, you might as well include the signature in the HTTP headers.

This is what is achieved by a number of proprietary authentication schemes today. For example Amazon S3 REST authentication and Windows Azure Platform both use HMAC based signatures located in the HTTP Authorization header. Those signatures cover the payload as well as the verb, the URI and other key headers.

OAuth v1 also defined a standard signature based token which does just this: it covers the verb, the uri, the payload, and other crucial headers. This is an elegant way to achieve integrity for REST. Unfortunately, OAuth v2 dropped this signature component of the specification. Bearer type tokens are also useful but, as explained by Eran Hammer-Lahav in this post, dropping payload signatures completely from OAuth is very unfortunate.


Connecting the enterprise to the cloud marketplace

March 11, 2010

With Google launching its new cloud-based enterprise apps marketplace these days, many people are paying closer attention to a maturing overall cloud offering. One of its components which caught my attention today is ironically something that you are meant to install enterprise-side: the Secure Data Connector (SDC).

The SDC lets the enterprise control access to its private resources (resources behind the enterprise’s firewall) from google apps. This illustrates an increasingly popular pattern relating to enterprise cloud adoption where applications deployed on the cloud need to access private resources located securely behind the enterprise’s firewalls. This pattern is also referred to as the ‘distributed SOA’, the idea that an enterprise’s SOA spans across multiple service zones both on and off-premise.

Google’s SDC is essentially reverse-proxy software, which you install on a server deployed in your DMZ. SDC maintains a secure link with Google apps and enforces basic rules relating to access control. Although some aspects of the solution borrow concepts from standards such as OAuth, the solution as a whole is mostly proprietary.

There is no doubt that this pattern is very important to address for any enterprise leveraging cloud-side applications. However, before deploying Google’s own gateway, and the ones of each cloud provider that you will eventually rely on, consider a best-of-breed specialized piece of infrastructure (SOA gateway) that works across cloud providers using standards and meets the highest threat protection requirements.

As it is, google apps access private resources through such an SOA gateway just as well as they will through the proprietary SDC. This type of openness is crucial in your choice of cloud provider. Proprietary security mechanisms increase vendor lock-in – perhaps one of the most important barrier to adoption for rich enterprise cloud use. Investing in security solutions that only works with one cloud platform affects your long term ability to switch provider.


JSON Schema validation for RESTful Web services

January 18, 2010

In The importance of threat protection for restful web services, I presented a number of content-based threats for XML. When protecting an endpoint from XML based attacks, not only are payloads scanned for code injections, malicious entity declarations and parser attacks, XML documents are actually validated against strict schemas that clearly describe expected document structures. Enforcing this type of compliance at the edge, in a SOA gateway for example, minimizes the risk of attacks of the Web service endpoint. Structure definition languages such as XML Schema Definition (XSD), schematron, XPath are all helpful tools in describing the type of data and structure of XML documents that are expected at runtime.

JavaScript Object Notation (JSON) is increasingly being considered as an alternative to XML and already established as the preferred content-type for many RESTful Web services and APIs. JSON-enabled services that receive content from external sources are subjected to similar message level threats as XML based web services. The need for validation of JSON payload structures is an essential component of perimeter threat protection for JSON capable environments. An existing schema language specification for JSON named JSON Schema uses concepts similar as XSD to provide JSON structure definition. Also worth nothing is an alternative named Orderly which proposes a different specification using leaner syntax.

A number of recent posts illustrated the use of the SecureSpan SOA Gateway for the protection of RESTful Web services. In How to secure REST and JSON, Scott illustrated how to virtualize a REST API service, how to authenticate and authorize requesters, provide confidentiality, validate incoming query parameters, block code injections, and more. In addition to this, consider the SecureSpan JSON Schema validation assertion which can be incorporated in SecureSpan policies. In the service policy illustrated below, PUT requests are inspected for proper JSON structure using this assertion.

This assertion’s properties allow the administrator to provide a JSON Schema for runtime validation. See below a simple JSON Schema loaded in the assertion’s properties.

For testing this policy, we can PUT requests to this service using the Firefox REST Client plugin. This lets us verify that only JSON stuctures that comply with the JSON Schema are accepted.

Test 1 – Sending a JSON payload that conforms to the JSON Schema.

Test 2 – Sending a JSON payload that violates the JSON Schema prescribed structure.

The ability to validate incoming JSON payloads at the perimeter, in an isolated and secured environment is another example of SecureSpan’s value in securing RESTful environments.


The importance of threat protection for RESTful web services

January 6, 2010

Although certain RESTful web services are of a ‘public’ nature and do not have specific security requirements such as authentication and authorization, any service that has an entry point from an untrusted network is subject to attack and proper threat protection measures are always an essential consideration.

RESTful web services are closely aligned to the web itself and as such inherit all traditional threats from the web. Although network level threats are well understood and addressed by traditional firewall infrastructure, RESTful web services type APIs are also subject to content (or message) level threats.

For example, consider APIs where XML payloads are POSTed and/or PUT from external requesters. A particularly dangerous threat was uncovered last summer involving a vulnerability in most XML parsing libraries used at the time. Any REST web service using those XML parsing libraries could have easily been crippled. In fact, I would expect many deployments out there still using vulnerable versions of those XML parsers today.

Despite fixes applied to parsing libraries to address such vulnerabilities, many potential content-level attacks continue to pose a threat. Consider for example external entity attacks, where a parser is tricked into resolving a resource from a malicious source. Also, SQL injections which were recently at the center of the largest data breach in US history . Many other threats specifically targeting XML enabled services exist such as recursive payloads, schema poisoning and coercive parsing to name a few.

Of course, REST is not bound to XML only. Threat protection for RESTful web services has to potentially consider a number of other content-type specific threats such as for JSON.


Follow

Get every new post delivered to your Inbox.