April 5th, 2012

Simplifying SOAP-to-REST Conversion

Written by

SOAP-to-Rest RemappingEarlier this week, Layer 7 CTO Scott Morrison presented our second Tech Talk Tuesday meet-up on Facebook, which concentrated on Simplifying REST Adaptation. For those of you who missed the live event, the recording is now available in the Layer 7 Resource Library. For those of you who attended, I thought I’d provide some detailed information on how Layer 7 facilitates bulk conversion of SOAP-based Web services to RESTful APIs.

We’ve previously provided some insight into the process of translating between REST and SOAP in a tutorial on our Web site. In that tutorial, we demonstrated how our policy language lends itself to a simple way of defining the conversion process, making converting REST to SOAP a fairly trivial exercise. However, if you have tens or hundreds of existing SOAP services, translating them all to REST might seem somewhat daunting.

Luckily, a Layer 7 Gateway can also help to make that process considerably easier – and I’m going to show you how. I’ll be walking you through a wizard that makes it simple to (a) upload your Web services to the Gateway as WSDLs and then (b) customize how you want the REST version of each service to look.

First, you upload your WSDL.

SOAP-to-REST Step 1

Then, configure how you would like to present your REST interface.

SOAP-to-REST Step 2a

Each operation can be customized with the type of HTTP method used.

SOAP-to-REST Step 2b

Once you submit your configuration, you’re ready to go!

At the end of the wizard, sample HTML-based documentation is provided that can be used for presenting the REST endpoint to your clients. This documentation is the first step in presenting the details of your new RESTful API via the Layer 7 API Portal.

SOAP-to-REST Step 3b1

Here’s an example of the same operation above that was converted to a HTTP GET style.

SOAP-to-REST Step 3b2

Finally, we also provide a sample WADL based on the parameters that you specify.

SOAP-to-REST Step 3c

Once you login to the Layer7 Policy Manager, you’ll find a predefined policy that does all the conversion from REST to SOAP.

SOAP-to-REST Step 4

From here, you can add any additional policy enforcement requirements as you see fit.

March 29th, 2012

Simplifying REST Adaptation: Live Facebook Q&A with Layer 7 CTO Scott Morrison

Written by
Category API, Events, REST, Tech Talks

Tech Talk TuesdayIt was live, it was unscripted and it was awesome. Tech Talk Tuesday – the first ever live Layer 7 Facebook interactive chat – was a huge success. I mediated the Livestream and Francois Lascelles, Layer 7′s Chief Architect, took the hot seat, answering questions live through the Layer 7 Facebook page. Questions came from all over the world and Francois did a great job of thinking on his feet, answering some very tough questions around OAuth. In case you missed it, you can watch the recording here.

And now it’s time for the next episode. We’re excited to announce that Scott Morrison, our CTO, will be the guest expert and he’ll be taking questions on how you can simplify REST adaptation using existing IT infrastructure. So save the date – on Tuesday April 3, we’ll be streaming live at 9am PST. Start thinking of some great questions to ask Scott and be sure to tell your colleagues about this rare opportunity to chat live with Layer 7′s CTO.

To join the session, simply go to the Layer 7 Facebook page and click the Livestream icon. Once the Livestream app is open, click the play button and you’ll be watching the stream live. If you want to ask a question, click the big red button that says “check in and chat” and bang you’ll be ready to chat live with Layer 7. We’re really excited about this talk and anticipate lots of audience engagement. So we’ll see you next Tuesday April 3, live on Facebook.

February 7th, 2012

API Management – Infrastructure Versus SaaS

API Management - Infrastructure Versus SaaS

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, think about these key considerations:

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 for hosting 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 resource utilization. IaaS and private Cloud-based API management infrastructure also provide elasticity and can scale on demand. Look for an API management solution that offers 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 can 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, 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 costing more than any initial costs savings.

Agility, Integration
SaaS solutions provide easy-to-use systems isolated in their own silos. 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 or 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 these systems together. Integrating your API management with existing identity infrastructure can be important to achieving runtime access control. Integrating with billing systems is crucial to monetizing your APIs. Feeding metrics from an API management infrastructure into an existing BI infrastructure provides better visibility.

Depending on the audience for your APIs, various regulations and security standards may apply. Sensitive information traveling through a SaaS-based system is outside 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.

Detours increase latency. By routing API traffic through a hosted system before it gets to the source of the data, you introduce detours. By contrast, if you architect an API management infrastructure in such a way that runtime controls happen in the 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.

I'll be touching upon some of these issues when I give a presentation called Enterprise Access Control Patterns for REST & Web APIs on March 2, at the RSA Conference in San Francisco.

December 22nd, 2011

The Future is a Story About Mobile Computing

Written by
Marc Andreessen

Earlier today, CNET published an interview with Marc Andreessen, in which the Netscape founder and influential VC outlines his personal vision for where tech is heading in the near future. His new tagline, from a piece he wrote for the New York Times, is “software is eating the world”, a blunt reference to how software increasingly appears out of nowhere to utterly consume a traditional practice or business model — be this in commerce, the social realm or just about everywhere.

Andreessen asserts that this affect will only accelerate in the future because of the explosion we are experiencing in mobile computing:

"Most of the people in the world still don’t have a personal computer, whereas in three to five years, most people in the world will have a smartphone…. If you’ve got a smartphone, then I can build a business in any domain or category and serve you as a customer no matter where you are in the world in just gigantic numbers — in terms of billions of people."

This new scale of mobile is something we’re only beginning to see but it is becoming clear that the change this will bring about is going to be profound. Mobile computing is very interesting to Layer 7 — watch our for some interesting new developments coming out of our labs early in the new year.

I discovered a similar indicator of mobile interest using Google’s Insights for Search. Pete Soderling and Chris Comerford from Stratus Security Technologies gave an excellent talk, back in 2010 at the RSA show, about REST security. They illustrated how the zeitgeist around distributed computer communications was changing over time, by comparing search volume for “SOAP Security” (blue line) and “REST Security” (red line):

Try this out for yourself here.

What struck me about this was not that REST came up so fast — you’d have to be living under a rock to have missed that one — but that the two approaches have been tracking roughly equivalent over the last year. This mirrors our own experience at Layer 7, where we support both SOAP and REST security equally. We see similar patterns of interest coming from our customers.

What is even more interesting is what happens when you add “Mobile Security” (yellow line) to the mix:

Try it here.

The future indeed, will be written from a hand-held device.

September 16th, 2011

OAuth Client Broker Tooling

In terms of OAuth enterprise tooling, a lot of focus is given to OAuth-enabling APIs exposed by the enterprise itself. Naturally, the demand for this reflects today’s reality where the enterprise is increasingly playing the role of an api provider. However, many enterprise integration use cases involving cloud-based services puts the enterprise in the role of API consumer, rather than provider. And as the number of enterprise applications consuming these external APIs grows, and the number of such external APIs themselves grows, point-to-point OAuth handshakes become problematic.

Another challenge relating to consuming these external APIs is that OAuth handshakes are geared towards a client application driven by a user. The protocol involves a redirection of that user to the API provider in order to authenticate and express authorization. Many enterprise integration (EI) applications do not function in this way. Instead their behavior follows a machine-to-machine transaction type; they operate at runtime without being driven by a user. Wouldn’t it be great if these EI apps could benefit from the OAuth capabilities of the APIs and still operate in headless mode? The so-called ‘two-legged’ OAuth pattern provides a work around for this challenge but requires the client app to hold resource owner credentials, which is problematic, especially when replicated across every client app.

To illustrate how an enterprise API management solution can help manage this challenge, I demonstrate an OAuth tooling geared towards brokering a client-side OAuth session with the Salesforce API using the Layer 7 Gateway. By proxying the Salesforce API at the perimeter using the Layer 7 Gateway, my EI apps do not have to worry about the API provider OAuth handshake. Instead, these EI apps can be authenticated and authorized locally using the Enterprise identity solution of choice and the Layer 7 Gateway manages the OAuth session on behalf of these applications. The benefits of this outbound API proxy are numerous. First, the OAuth handshake is completely abstracted out of the EI apps. In addition, the enterprise now has an easy way to manage control of which applications and enterprise identities can consume the external API, control of the rates of consumption and monitor usage over time. The API can itself be abstracted and the proxy can transform API calls at runtime to protect the consuming apps from version changes at the hosted API side.

To set this up on the Layer 7 Gateway, you first need to register a remote access to your Salesforce instance. Log into your Salesforce instance and navigate to Setup -> App Setup -> Develop -> Remote Access. From there, you define your remote access application. The callback URL must match the URL used by the Layer 7 Gateway administrator at setup time in the Layer 7 Gateway. Make sure you note the Consumer Key and Consumer Secret as they will be used during the OAuth handshake setup; these values will be used by your Layer 7 OAuth broker setup policy.

Using the Layer 7 Policy Manager, you publish your broker setup policies to manage the OAuth handshake between the Gateway and your Salesforce instance. Note that the OAuth callback handling must listen at a URL matching the URL defined in Salesforce. These policies use the consumer key and consumer secret associated with the registered remote access in your Salesforce instance. The secret should be stored in the Gateway’s secure password store for added security. Use templates from Layer 7 to simplify the process of setting up these policies.

Once these two policies are in place, you are ready to initiate the OAuth handshake between the Layer 7 Gateway and the Salesforce instance. Using your favorite browser, navigate to the entry point defined in the admin policy above. Click the ‘Reset Handshake’ button. This will redirect you to your Salesforce instance. If you do not have a session in place on this browser, you will be asked to authenticate to the instance, then you are asked to authorize the client app (in this case, your Layer 7 Gateway). Finally, you are redirected back to the Layer 7 Gateway admin policy which now shows the current OAuth handshake in place. The admin policy stores the OAuth access token so that it can be used by the api proxy at runtime.

Your Layer 7 Gateway is now ready to act as an OAuth broker for your EI apps consuming the Salesforce API. You can publish a simple policy to act as this proxy. This policy should authenticate and authorize the EI app and inject the stored OAuth access token on the way out. Note that this policy can be enhanced to perform additional tasks such as transformation, rate limiting, caching, etc.

Although this use case focuses on the Salesforce API, it is generally applicable to any external API you consume. You can maintain an OAuth session for each API you want to proxy in this Gateway as well as perform identity mapping for other external access control mechanism, for example AWS HMAC signatures.