March 31st, 2011

The ESG pattern


Category Uncategorized
 
Are you still considering rolling out a major Enterprise Service Bus (ESB) stack — you know, the kind that involves a massive initial investment and takes 8+ months to deploy? This wasteful approach was a major factor in doomed corporate SOA initiatives that were common between 2003 and 2009. During this same period, clever architects ignored large vendor promises and realized that you simply cannot buy your way into an agile enterprise SOA. They instead focused on the tasks at hand, integrating existing IT assets, following SOA principles, using existing tools and adding lightweight strategic and specialized infrastructure to help them along the way. The winning enterprise SOA initiatives are the ones who made sure that the SOA was operational as it evolved. SOA Gateways gained popularity in recent years as a lightweight ESB that can span departmental boundaries. Like software ESBs, SOA Gateways can translate data formats, route content, service-enable data sources and switch between transport protocols. But SOA Gateways have a number of significant advantages over traditional software ESBs. For example, they scale easily and accommodate high volume traffic environments owing to their specialized acceleration of message validation, routing and translation. Also, SOA Gateways offer comprehensive security and identity federation features built in so they can be deployed at the service zone perimeter (think DMZ). Looking back, the pattern of using an SOA Gateway to integrate and service-enable existing IT assets has been a large success. Because of the appliance form factor and the configure, not code approach, the cost of integration and the time to react to new requirements both shrunk considerably. And with a focus increasingly shifting towards cloud computing, this ability to quickly accommodate new integration mechanisms has already paid off for those who invested in the lightweight, agile solution. This is especially the case for those who opted for the virtual appliance form factor. I like to refer to this pattern as the Enterprise Service Gateway (ESG). That is, the ability to execute integration, transformation and security using a specialized gateway appliance as opposed to coding using traditional software ESB frameworks.
March 30th, 2011

The API Gateway As Endpoint

Written by
Category API, Security, SOA
 
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.