We actually have a lot to offer to secure, monitor and manage REST-style transactions.

The truth is, although we really like SOAP and XML here at Layer 7, we also really like REST and alternative data encapsulations like JSON.

We use both REST and JSON all the time in our own development.

Suppose you have a REST-based service that you would like to publish to the world, but you are concerned about access control, confidentiality, integrity, and the risk from incoming threats.

We have an answer for this: SecureSpan Gateway clusters, deployed in the DMZ, give you the ability to implement run time governance across all of your services:

Pictures are nice, but this scenario is best understood using a concrete example. For the services, Yahoo’s REST-based search API offers us everything we need–it even returns results in JSON format, instead of XML.

Let’s imagine that I’m deploying a SecureSpan Gateway in front of the servers hosting this API, as I’ve illustrated above. The first thing I will do is create a very simple policy that just implements a reverse proxy. No security yet–just a level of indirection (click on the picture for detail):

This is just about as simple as a policy can get. Notice that the validator is warning me about a few potential issues. It’s pointing out that the transaction will pass arbitrary content, not just XML.

Because I’m expecting JSON formatted data in the response, this is the behavior I expect. The validation is also warning me that this policy has no authentication at all, leaving the service open to general, anonymous access.

We’ll address this in the next step.

I’ve explicitly attached this policy to the gateway URL:

http://scottssg/yahooImageSearch

If need be, I could easily add wild card characters here to cover a range of incoming URLs. For this demonstration, I’m just running a virtual SecureSpan Gateway here on my Macbook; it’s not actually residing in the Yahoo DMZ, as would be the case in a real deployment. But from the perspective of an administrator building policy, the process is exactly the same regardless of where the gateway lives.

I’ve also placed a restriction on the listener to only accept HTTP GET verbs:

Now I can point my web browser to the gateway URL shown above, and get back a JSON formatted response proxied from Yahoo. I’ll use the same example in the Yahoo tutorial, which lists pictures of Madonna indexed by Yahoo:

which I’ve truncated a lot because the actual list spans thousands of characters. The Yahoo tutorial must be fairly old; when it was written, there were only 631,000 pictures of the Material Girl. Clearly, her popularity continues unabated.

Now let’s add some security. I’d prefer that nobody on the Internet learns that I’m searching for pictures of Madge, so we need to implement some privacy across the transaction. I can drag-and-drop an SSL/TLS assertion into the top of my policy to ensure that the gateway will only accept SSL connections for this RESTful service. Next, I’ll put in an assertion that checks for credentials using HTTP basic authentication. I’ll use the internal identity provider to validate the username/password combination. The internal identity provider is basically a directory hosted on the SecureSpan Gateway. I could just as connect to an external LDAP, or just about any commercial or open source IAM system. As for authentication, I will restrict use of the yahooImageSearch REST service to members of the development group:

Virtualization of the internal service, and publication to authorized users

This is good, but I’d like to add some more REST-specific constraints, and to filter out potential REST attacks that may be launched against my service. I can do this with two simple assertions: one that validates form field in HTML, and another that scans the content for various code injection signatures:

The form data assertion allows me to impose a series of tight constraints on the content of query parameters. In effect, it let’s me put a structural schema on an HTTP query string (or POST parameters). I’m going to be very strict here, and explicitly name every parameter I will accept, to the exclusion of all others. For the Yahoo search API, this includes:

appid

query

output

callback

The later does some wrapping of the return request to facilitate processing in JavaScript within a browser:

Depending on my security requirements, I could also be rigorous with parameter values using regular expressions as a filter. I’ll leave that as an exercise for the reader.

Naturally, I’m concerned about REST-born threats, so I will configure the code injection assertion to scan for all the usual suspects. This can be tuned so that it’s not doing unnecessary work that might affect performance in a very high volume situation:

That’s it–we’re done. A simple 6 assertion policy that handles confidentiality, integirty, authentication, authorization, schema validation, threat detection, and virtualizatoin of RESTful JSON services. To call this, I’ll again borrow directly from the Yahoo tutorial, using their HTML file and simply change to URL to point to my gateway instead of directly to Yahoo:

<html><head><title>How Many Pictures Of Madonna Do We Have?</title></head></body><script type="text/javascript">function ws_results(obj) {alert(obj.ResultSet.totalResultsAvailable);}</script><script type="text/javascript" src="https://scottssg:8443/yahooImageSearch?appid=YahooDemo&query=Madonna&output=json&callback=ws_results"></script><body></body></html>

Still can’t get over how many pictures of Madonna there are.

I ran it a few times and here’s what it looks like in the dashboard. I threw in some policy failures to liven up the display:

So where can we go from here? Well, I would think about optimization of the policy. Depending on predicted loads and available hardware, we might want to check for code injection and validate the schema before performing authentication, which in the real world would likely call out to an LDAP directory. After all, if we are being fed garbage, there’s no sense in propagating this load to the directory.

We can add SLA constraints across the service to insulate back end hosts from traffic bursts. We could also provide basic load distribution across a farm of multiple service hosts. We might aggregate data from several back-end services using lightweight orchestration, effectively creating new meta-services from existing components.

SecureSpan Gateways provide over 100 assertions that can do just about anything want to an HTTP transaction, regardless of whether it contains XML or JSON data. You can also develop custom assertions which plug into the system and implement new functionality that might be unique to your situation.

Remember: when you are an intermediate, standing in the middle between a client and a service–as is the case with any SecureSpan Gateway–you have complete control over the transaction, and ultimately the use of the service itself.

This has implications that go far beyond simple security, access control, and monitoring.

K. Scott Morrison is the Chief Technology Officer and Chief Architect at Layer 7 Technologies, where he is leading a team developing the next generation of security infrastructure for cloud computing and SOA. An architect and developer of highly scalable, enterprise systems for over 20 years, Scott has extensive experience across industry sectors as diverse as health, travel and transportation, and financial services. He has been a Director of Architecture and Technology at Infowave Software, a leading maker of wireless security and acceleration software for mobile devices, and was a senior architect at IBM. Before shifting to the private sector, Scott was with the world-renowned medical research program of the University of British Columbia, studying neurodegenerative disorders using medical imaging technology.

Scott is a dynamic, entertaining and highly sought-after speaker. His quotes appear regularly in the media, from the New York Times, to the Huffington Post and the Register. Scott has published over 50 book chapters, magazine articles, and papers in medical, physics, and engineering journals. His work has been acknowledged in the New England Journal of Medicine, and he has published in journals as diverse as the IEEE Transactions on Nuclear Science, the Journal of Cerebral Blood Flow, and Neurology. He is the co-author of the graduate text Cloud Computing, Principles, Systems and Applications published by Springer, and is on the editorial board of Springer’s new Journal of Cloud Computing Advances, Systems and Applications (JoCCASA). He co-authored both Java Web Services Unleashed and Professional JMS. Scott is an editor of the WS-I Basic Security Profile (BSP), and is co-author of the original WS-Federation specification. He is a recent co-author of the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing, and an author of that organization’s Top Threats to Cloud Computing research. Scott was recently a featured speaker for the Privacy Commission of Canada’s public consultation into the privacy implications of cloud computing. He has even lent his expertise to the film and television industry, consulting on a number of features including the X-Files. Scott’s current interests are in cloud computing, Web services security, enterprise architecture and secure mobile computing—and of course, his wife and two great kids.

Adobe ColdFusion software solves the day-to-day challenges of Internet application development, allowing Web application developers to be extremely productive as they create and deliver engaging online applications. And because it fits into any IT environment, Web designers can use ColdFusion for everything from small departmental applications to highly scalable, reliable implementations of the most important business applications. ColdFusion Developer's Journal was first launched 12 years ago. Ulitzer brings more than 7,000 original CFDJ articles and ColdFusion authors from archives in ColdFusion Developer's Journal 2.0.

Cloud Expo

Cloud Computing & All That
It Touches In One Location Cloud Computing - Big Data - Internet of Things
SDDC - WebRTC - DevOps
Cloud computing is become a norm within enterprise IT.

The competition among public cloud providers is red hot, private cloud continues to grab increasing shares of IT budgets, and hybrid cloud strategies are beginning to conquer the enterprise IT world.

Big Data is driving dramatic leaps in resource requirements and capabilities, and now the Internet of Things promises an exponential leap in the size of the Internet and Worldwide Web.

The world of SDX now encompasses Software-Defined Data Centers (SDDCs) as the technology world prepares for the Zettabyte Age.

Add the key topics of WebRTC and DevOps into the mix, and you have three days of pure cloud computing that you simply cannot miss.

Delegates will leave Cloud Expo with dramatically increased understanding the entire scope of the entire cloud computing spectrum from storage to security.

Cloud Expo - the world's most established event - offers a vast selection of 130+ technical and strategic Industry Keynotes, General Sessions, Breakout Sessions, and signature Power Panels. The exhibition floor features 100+ exhibitors offering specific solutions and comprehensive strategies. The floor also features two Demo Theaters that give delegates the opportunity to get even closer to the technology they want to see and the people who offer it.

Attend Cloud Expo. Craft your own custom experience. Learn the latest from the world's best technologists. Find the vendors you want and put them to the test.