February 25th, 2013

SSO & OAuth for Mobile Apps – Live Discussion, Feb 26

OAuth SSO Tech TalkIn case you haven’t heard, we are living in the age of mobile applications and the APIs that power them. Sometimes it’s called the API economy.

Smart phones are ubiquitous, social networks are the norm and we are connected to applications on our devices all the time. We love applications like Instagram, Twitter, Evertnote and Snapchat. But we don’t like signing in and out of each of these applications across networks or devices. It’s awkward and cumbersome and we’re often doing it while on the go or commuting, with only one hand to use while tapping in our passwords. Besides, who wants to remember all those passwords anyway? And it’s not safe to use the same one for every application.

This is the major downside of using all these great new mobile applications. Most of us would gladly invite a scenario where we’d only need to log in once to access multiple applications. There’s social login – but is it safe and is our privacy secure? Remember what happened to Burger King’s Twitter account? Enter Single-Sign-On & OAuth for Mobile Applications.

On Tuesday Feb 26, we’ll be hosting a live interactive Tech Talk on security and Single Sign-On (SSO) for mobile applications. And I’m excited to welcome back Layer 7′s Chief Architect and resident OAuth expert Francois Lascelles. He’ll discuss how to provide SSO for mobile applications, without compromising the security of the apps or the APIs that power them. Francois will also be taking your questions throughout the Tech Talk. So, this will be a great opportunity to get answers to your questions about your own applications and the security that surrounds them.

Click here to get the event details and a reminder in your calendar.

On the day of the event, click here to join:

Submit your questions:

February 7th, 2013

“Mobile App Security: Always Keep the Back Door Locked” – Our Take

Mobile App SecurityToday’s lead article on Ars Technica talks about the importance of protecting backend resources in the context of mobile applications. The article rightly stresses the importance of this security, talks about the uptake in OAuth and cites API Gateway solutions as a popular option in this space.

However, the article clearly misstates the capabilities of an API Management solution founded on an API Gateway. I am going to assume that the author only had exposure to API Gateways second hand or through a competitor of Layer 7. Here are the misconceptions propagated by the article, along with some corrections:

“These API gateway services can be prohibitively expensive for small-scale applications…  ‘You can replicate the API gateway by creating a set of proxy services in their data center in an application container in their DMZ.’”

Trying to create your own homegrown set of proxy services is expensive and risky. The Layer 7 API Management Suite’s Gateway technology includes 10 years of functional enrichment and optimization. Such robustness cannot be hacked together on the fly.

“An API gateway still runs on the notion that you have to be careful not to block what might be legitimate traffic. So that could cause some openness – some attacks might slip through using Web application firewall evasion techniques.”

An API Gateway is not a typical web application firewall. Layer 7’s Gateway (evident in the company’s name) has full access to all layers of the data stream and can apply protections at any of these layers.

“Of course, if they can retrieve a developer key, attackers can slip past API gateways until their activity is noticed…  That’s why it’s important to encrypt any data stored on the device, including developer keys[.]”

API keys are not treated as security tokens by an API Gateway. The term “API key” is equivalent to a “database key”, not a security key, so don’t mistake it for a robust access control mechanism. It is mainly an identification mechanism. It is a gross misunderstanding to equate API developer keys with a standard access control cryptographic mechanism like PKI public/private keys.

“But keys have other ways of getting into the wild besides breaking into the application code.”

Right, so you should not rely on these keys for access control. The good news is that the API Management Suite’s Portal/Gateway combination makes it easier to revoke and reissue developer keys.

“For enterprise applications, an API gateway isn’t always enough – users need to get access to content on servers inside the firewall that may not be easily exposed through a Web API.”

And this is where the API Gateway really adds value. The Layer 7 API Management Suite allows companies to turn those backend interfaces from their native protocols into REST APIs or other formats that are friendly to mobile devices.

So, thanks to Ars Technica for flagging up this important aspect of mobile security and here’s hoping that this corrected information is included in the next article.

December 3rd, 2012

A Break in the Clouds

A Break in the CloudsA recent study by researchers at North Carolina State University and the University of Oregon describes a threat scenario that allows attackers to exploit cloud-based resources for malicious purposes like cracking passwords or launching denial-of-service attacks. The study has gotten a lot of attention, including articles in reputable sources like Dark Reading, Ars Technica and Network World.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.

October 12th, 2012

Dispatches from NY
Don’t be a Control Freak

Interop New YorkA week back, I had the privilege of joining some industry peers at New York’s Interop conference, to discuss trends in enterprise mobility. Each of the companies represented a sub-segment of the mobility space. We had a big data company, an MDM vendor, a client virtualization company and me representing the MBaaS wing. Each presenter made a case for why their sub-segment is essential to enabling the mobile enterprise.

Not surprisingly, they all emphasized their security and management credentials as being central to their value propositions. Each vendor took a different approach to protecting the welfare of the enterprise but in the end, we all promised we could defend organizations against risk, both technological and financial. What we neglected to mention, I realized afterwards, was that a little risk is sometimes good.

Don’t get me wrong, security is something I take seriously. We at Layer 7 guard some of the most sensitive government and commercial APIs against cyber attack and misuse. But there is a downside to an unbalanced emphasis on insecurity – and that is fear. Some fear ensures prudence. Too much fear can arrest the progress of whole industries.

In a few short years, smart mobile devices have completely transformed how we communicate, socialize, shop and get entertained. Almost overnight, an economy has grown up around mobile apps. This same app explosion is poised to change how enterprises function, by completely un-tethering employees, while providing a way for companies to reach their customers beyond the PC and TV. But to get there, enterprises will have to encourage app innovation and the only way to achieve that is by opening up.

Now, no one says that opening up needs to be a foolhardy effort. Opening up data and applications to mobile apps needs to be done in a guarded and prudent manner. But in all the talk around mobile security, it’s important not to stifle innovation around mobile development. Security has to go hand-in-hand with connectivity.

August 7th, 2012

Using WebSockets – Part 1: Minding the Gates

HTML 5 and WebSocketOne of the most exciting features introduced with HTML5 was support for WebSockets. The WebSocket protocol has been through a lot of churn over the last two years, with browser vendors desperately trying to keep pace with changes in the specification. Thankfully, the standard has now become stable enough to be utilized in enterprise projects.

The beauty the WebSocket protocol is that it lets an application seamlessly move from an HTTP/Web-based flow into a socket-based conversation and then back to a Web-based flow. In this way, it allows Web- and mobile-based applications to easily move from the traditional request-reply HTTP world into new forms of full-duplex, bi-directional communication.

We’ve seen a similar evolution in the past within the message-oriented middleware world. With the emergence of SOA and API, enterprises realized they needed new ways of moving data around and middleware technologies emerged that facilitated the movement of data in ways that were not possible with existing request-reply synchronous messaging infrastructures.

Traditionally, Web and mobile applications had to work hard in order to send or receive real-time data. Now, developers can use WebSocket to move data up and down the communication channel quickly and efficiently. This is like moving from an email client that requires you to constantly check for new mail to one that instantly alerts you when a new email arrives.

This style of communication will provide enormous benefits for applications that require messages to be passed quickly between the client and server.  Architects will have an easier time building applications with real-time messaging requirements, opening the door to some very intriguing solution designs.  Targeted notification systems, more-responsive UIs and even complex architectures such as massive grid networks built on top of the Web will be much easier to implement properly.

But, what’s missing from the WebSocket story is an effective way of minding the gates. The “black hat” guys already see WebSockets as representing a new attack surface, so organizations that are serious about providing reliable, scalable solutions will require some form of Gateway on the server side, to guard against security breaches.

To address WebSocket security, a Gateway must be able to enforce SSL handshakes, limit the number of connection requests, protect against payload injection attacks and enforce strong authentication methods – the same set of attack vectors that exist for SOAP/XML Web services and REST/JSON APIs.

That’s why I’m particularly excited about Layer 7′s recently-announced SecureSpan Mobile Access Gateway product. The Mobile Access Gateway extends Layer 7’s industry-leading technology for SOA and API in order to address mobile-specific concerns – and it includes a very secure WebSocket implementation.

In addition to the security benefits, the Gateway can be used to enrich or filter data in real-time. This opens the door to a new set of compelling use cases that includes data auditing, image watermarking and blacklist filtering – possibilities intriguing enough to stand on their own as justifications for implementing a WebSocket Gateway.

So, we’ve discussed what the WebSocket protocol is and why it’s so important to keep WebSockets secure. But how does all this fit into the exciting world of APIs that we’ve been focusing on in many of our recent blog posts? Our Principal API Architect Mike Admundsen will tackle this question next week, in our continuing series on this very important protocol.