Monthly Archives: March 2011

The API Gateway As Endpoint

The US Customs and Immigration station at Point Roberts is a small building set on the edge of the coastal rainforest of Washington State. It is the last customs station in a vast western chain strung out along the 49 parallel. I enjoy crossing the border at Point Roberts. The abrupt change from sprawling Canadian suburbs to American rural countryside always appeals to me.

The customs station, despite it’s small size, offers a range of services from granting a visa to simply giving advice about where to find a good deal for gas in Point Roberts. It’s not simply a gateway controlling access into the US, but a provider of a broad range of services associated with crossing an international boundary.

There exists a similar duality with API gateways. Although the common deployment is as a border guard, protecting APIs hosted by an organization, an API gateway can also act as an endpoint providing valuable standalone services. Nearly all of my customers first purchase SecureSpan Gateways to fulfill the role the name implies: that is, an API or service gateway. The border guard deployment pattern is now so commonplace that I no longer need to evangelize it as I did in the early days of Layer 7, close to a decade ago. Architects recognize this pattern as an accepted best practice for securing and managing APIs. But like the Point Roberts border station, a SecureSpan Gateway can also provide services that have nothing to do with access control or transaction confidentiality, but provide value on their own, independent of any APIs they may be guarding.

Here’s a very simple example illustrating the endpoint pattern using a SecureSpan Gateway. Normally I might deploy my gateway in front of a web server, acting as an authenticating reverse proxy for my web pages. In this role, the gateway is responsible for access control, SSL management, audit, lightweight load balancing, etc. All classic gateway functions.

Figure 1: Gateway as boarder guard at the edge of a network. This is classic perimeter security.

But suppose I wanted to use the gateway itself as the web server? In other words, it’s not acting as a gateway, but the server endpoint in itself?

Figure 2: Gateway as service endpoint. Here the gateway is providing valuable APIs on its own without necessarily routing a request to an internal host.

It’s very simple to configure a SecureSpan Gateway as an endpoint. You simply create a policy that never routes a request onward to an internal host, but instead acts on the message content internally. I sometimes think of it as an internal loop back mechanism. I’ll build a policy implementing my web site, and add the assertion Return Template Response to Requester. I will bind this policy to the gateway URL http://localhost:8080/helloworld as shown in the screen snippet below from the SecureSpan management console:

With just one assertion, this is pretty much the simplest policy you can write, and so fitting for the time-honoured Hello World example. Let’s expand the assertion to examine at what the template actually contains:

Pretty plain-vanilla HTML. The only departure I’ve made from the deliberate austerity of the Hello World tradition is to add a time stamp to showcase the use of predefined context variables. There are dozens of context variables that are automatically set as the gateway processes a transaction (regardless of whether it’s actually being a gateway or an endpoint—remember we consider this just a policy implementation pattern, not a different capability). Context variables cover everything from accessing individual fields in the X509 certificate used for client-side SSL authentication to storing the IP address of a request sender. And of course, you can set your own context variables at any time within a policy.

Just to be complete, here’s what happens when I point my browser at the gateway-as-endpoint:

Now, before you think I’ve gone mad, I am not advocating that you deploy a web site like this; there are much better tools for that purpose. But the point I’m making is that there are legitimate endpoint services that do indeed lend themselves to implementation on a gateway. These are just a little more complicated than what I’ve shown here, but nevertheless simple to implement using the declarative policy language in SecureSpan. For example:

  • Signing Services: In the notary pattern, a gateway with an on-board Hardware Security Module (HSM) responsible for protecting key material can easily provide authoritative signing services for all kinds of data, from XML documents to arbitrary text.
  • Encryption Services: Same idea as signing, with the goal to avoid insecure proliferation of keys.
  • Validation Services: Ensure data conforms to a particular schema.
  • Threat Detection Services: Scan content for SQL injection, Cross Site Scripting (XSS), XML threats, or custom threat signatures.
  • Security Token Services (STS): Issue security tokens like SAML or OAuth tokens. Validate or exchange tokens.
  • Centralized Session or Caching Management: Cache frequently used data items according to a scheme that is tuned to your application.
  • Policy Decision Point (PDP) Services: Receive and act on SAMLP requests.
  • XACML Services: Act as a centralized XACML engine providing authorization services.

The list above is by no means exclusive; however, at Layer 7 we’ve implemented all of these at one time or another using SecureSpan Gateways. It’s an important design point for us that the only real difference between a gateway and an endpoint is how you define your policy.

When Is The Cloud Not A Cloud?

Sometimes I joke that as my kids grow up they won’t see clouds, they’ll just see air—meaning of course that their use of cloud-based services will become so ubiquitous as to make the cloud moniker largely unnecessary. What we so enthusiastically label cloud will just be the way everyone builds and deploys their apps. “Nothing to see here folks; but look at my wonderful new application…”

We won’t arrive at this future until we strip the word cloud of its power. And to do this, we need to go after the things we thought made cloud unique and special in the first place. Today, Amazon took a vicious swipe at the canonical definition by introducing dedicated EC2 instances. Dedicating hardware to a single customer addresses the next logical layer in the hierarchy of security concerns after virtual isolation. Amazon’s VPC product, introduced back in August 2009, provided virtualized isolation in their multi-tenant environment. Essentially VPC is like a virtual zone housing only your instances. This zone is tied back to your on-premise network using a VPN. The only way in or out of a zone is through your corporate network. Other Amazon-resident applications can not access your apps directly—in fact, any external app, Amazon-resident or otherwise—must go through your conventional corporate security perimeter and route back to Amazon over the VPN to be able to gain access to a VPC app. The real value of VPC is that it puts instance access back into the hands of the corporate security group.

The problem that the highly security conscious organization has with VPC is that the “V” is for virtual. VPC may implement clever isolation tricks using dynamic VLANs and hypervisor magic known only to a gifted few, but when your critical application loads up you may actually reside on exactly the same hardware as your own worst enemy. In theory, neither of you can exploit this situation. But you need to believe the theory. Completely.

Today’s announcement means that Amazon’s customers can literally have exclusive use of hardware. This is good news for anyone with reservations about hypervisor isolation. However, the networking remains virtualized, and of course you can still ask the classic cloud security questions about where data resides, or the background of the staff running the infrastructure. So a mini-private cloud, it is not; but dedicated instances is an interesting offering, nonetheless.

What is more intriguing is that by providing dedicated hardware, Amazon is beginning to erode one of the basic foundations of the canonical cloud definition: multi-tenancy. Purists will argue—as they do so with unexpected vehemence with regard to private cloud—that what Amazon is offering is not a cloud at all, but in fact a retrograde step back to simple hosting or co-loc. I’m inclined to disagree, however, and think instead Amazon offers a logical next step (and certainly not the last) in the evolution of cloud services. By doing so, Amazon amplifies some of the other important aspects that define what the cloud really is. Things like self-service, a greatly changed division and scope of operational responsibility, the leverage of commodity of scale, elasticity, and the ability to pay for what you actually use.

I don’t think Amazon’s new offering will be wildly successful because it still leaves many security issues unresolved. But I do think it points the way to the future cloud, which will have many different attributes and characteristics that solve different problems. Some may conflict with traditional definitions and expectations. Some may fulfill them. What is important is to choose the service that meets your needs, and don’t worry what it’s called. That’s marketing’s problem.

Upcoming Webinar: Extending Enterprise Security Into The Cloud

On March 21, 2011 Steve Coplan, Security Analyst from the 451 Group and I will present a webinar describing strategies CIOs and enterprise architects can  implement to create a unified security architecture between on-premise IT and the cloud.

I have great respect for Steve’s research. I think he is one of the most cerebral analysts in the business; but what impresses me most is that he is always able to clearly connect the theory to its practical instantiation in the real world. It’s a rare skill. He also has a degree in Zulu, which has little to do with technology, but makes him very interesting nonetheless.

Lately Steve and I have been talking about the shrinking security perimeter in the cloud and what this means to the traditional approaches for managing single sign-on and identity federation. This presentation is a product of these discussions, and I’m anticipating that it will be a very good one.

I hope you can join us for this webinar. It’s on Tuesday, March 15, 2011 9:00 AM PST | 12:00 PM EST | 5:00 PM GMT. You can register here.

For years enterprises have invested in identity, privacy and threat protection technologies to guard their information and communication from attack, theft or compromise. The growth in SaaS and IaaS usage however introduces the need to secure information and communication that spans the enterprise and cloud. This webinar will look at approaches for extending existing enterprise security investments into the cloud without significant cost or complexity.

The API Lab

Promotion is a problem faced by every API developer. Long nights of coding have given form to the stroke of genius you had six months ago in the cafe. You’ve just written the API that will serve as the front door into your application. But how do you document this so that your peers will use it—and hopefully make you rich in the process?

Java had Javadoc, an innovation that managed to strike a surprisingly effective balance between ease of use and systematization (three cheers for strong typing and static binding). Web services “solved” the interface definition problem with WSDL, a standard only its authors could love (and some of these won’t admit to participating in conception). To the registry crowd was left the task of devising clever ways to document a SOAP API around the torturous abstractions of WSDL so that humans could grok it as effectively as the machines. Few would argue that their solutions were, well, solutions.

RESTful APIs neither benefit nor suffer from formalized approach and automation. Every so often WADL pokes its head up, only to be knocked decisively back into its hole in a community game of Standards-Whac-A-Mole. REST is—and indeed, has always been—a style that resists any formalism that threatens its simplicity and accessibility. For this, above all, the community deserves praise.

But this does leave a hole around documentation. APIs tend to be described-by-wiki, which can be great or just awful, depending on a developer’s ability to write and discipline to update. Good ideas like ProgrammableWeb showcase both of these extremes; however, the site suffers in particular from out-of-date API descriptions which is too bad.

Outside of the eventual acceptance en masse of some kind of standardized wiki template for APIs (which I think is actually quite likely), we probably won’t see substantial change in API documentation soon. Minor changes, though, can still count for a lot, and it’s worth pointing these out.

Google, always an innovator to watch, create a lot of APIs. They recently published the Periodic Table of Google APIs, which as its name suggests is a clever way to visually categorize their API portfolio into groups like mobile, data, geo, etc. It’s a bit gimmicky, but it is also fun and actually inspired me to try some new Google APIs that I wasn’t aware of before.

So, isn’t it about time for more creative solutions around API documentation?