July 26th, 2013

Next Tech Talk: CDN API Management Using Optimized API Distribution

API Tech Talk T-ShirtGet ready for Layer 7’s next API Tech Talk, coming up on Wednesday July 31 at 9am PDT. This live, interactive event will feature Akamai’s Gary Ballabio alongside our very own Francois Lascelles, chatting about CDN API Management Using Optimized API Distribution.

Right now, APIs are playing a central role in content providers’ efforts to maximize customer engagement by leveraging emerging online channels via cloud-based content distribution networks (CDNs).

But CDNs and API publishing have raised new access management and SLA enforcement challenges for content providers. On Wednesday, Gary and Francois will explain how content providers can tackle these challenges via entitlement checks, access history and analytics.

Our presenters will also be taking your questions and comments throughout the Tech Talk. And if they answer your question during the live stream, we’ll send you one of our highly desirable, limited edition Tech Talk T-shirts.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join us at:

You can ask questions throughout the stream by chatting or tweeting. Alternatively, just email your questions in advance so that Gary and Francois can give you some really in-depth answers on the day.

See you on Wednesday!

July 11th, 2013

Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity

Identity Federation WebinarThe adoption of cloud by organizations looking for more efficient ways to deploy their own IT assets or as a means to offset the burden of data management drives the need for identity federation in the enterprise. Compounding this is the mobile effect from which there is no turning back. Data must be available any time, from anywhere and the identities accessing it must be asserted on mobile devices, in cloud zones, always under the stewardship of the enterprise.

APIs serve federation by enabling lightweight delegated authentication schemes based on OAuth handshakes using the same patterns as used by social login. The standard specifying such patterns is OpenID Connect where a relying party subjects a user to an OAuth handshake and then calls an API on the identity provider to discover information about the user thus avoiding having to setup a shared secret with that user – no identity silo. This new type of federation using APIs is easier to implement for the relying party as it avoids parsing and interpreting complex SAML messages with XML digital signatures, both of which tend to suffer from interoperability challenges.

Now, let’s turn this around. Sometimes what needs to be federated is the API itself, not just the identities that consume it. For example, consider the common case of a cloud API consumed by a social media team on behalf of an organization. When the social media service is consumed from mobile apps, the cloud API is consumed directly and the enterprise has no ability to control or monitor information being posted on its behalf.

Cloud api consumption by mobile - not federated

In addition to this lack of control, this simplistic cloud API consumption on behalf of an organization by a group of users requires that users share the organization account itself, including the password associated with it. The security implications of shared passwords are often overlooked. Shared service accounts multiply the risk of a password being compromised. There are numerous recent examples of enterprise social media being hacked with disastrous PR consequences. Famous examples from earlier this year include Twitter hacks of the Associated Press leading to a false report of explosions at the White House and Burger King promoting competitor McDonalds.

Federating such cloud API calls involves the applications sending the API calls through an API broker under the control of the organization. Each of these API calls is made through an enterprise identity context, that is each user signs in with its own enterprise identity. The API broker then “converts” these API calls into API calls to the cloud provider using the identity context of the organization.

Cloud api, federated

In this case, federating the cloud API calls means that the enterprise controls the organization’s account. Its password is not shared or known by anybody outside of an administrator responsible for maintaining a session used by an API broker. Users responsible for acting on that cloud service on behalf of the organization can do so while mobile but are authenticated using their enterprise credentials. The ability of a specific user to act on behalf of an organization is controlled in real time. This can, for example, be based on attributes read from a user directory or a predefined white list in the broker itself.

By configuring policies in this broker, the organization has the ability to filter the information sent to and received from the cloud provider. The use of the cloud provider is also monitored and the enterprise can generate its own metrics and analytics relating to this cloud provider.

On July 23, I will be co-presenting a Layer 7 webinar with CA’s Ehud Amiri titled Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity. In this webinar, we will examine the differences between identity federation across Web, cloud and mobile, look at API-specific use cases and explore the impact of emerging federation standards.

April 18th, 2013

Intel Buys Mashery! Is it Because the Cloud Will Have an API Inside?

Intel-MasheryFor close to five years, Intel has had a stake in the API space. All the while, I’ve often asked myself why. Intel originally acquired an API Gateway from a prior Intel Capital investment that never fully blossomed. And despite the oddness of having a tiny enterprise software franchise lost inside a semiconductor behemoth, Intel persisted in its experiment, even in the face of questionable market success and lukewarm analyst reaction. So, why double down on APIs now?

With the steady decline of the PC business, Intel clearly has to look elsewhere for its future growth. The cloud datacenter is not a bad place to start. Cloud server farms clearly consume lots of processors. Still, servers powering Web sites can operate fine without APIs, thank-you. But servers powering mobile is a different story. Mobile apps (whether HTML5, hybrid or native) get the data that makes them valuable from applications that reside in datacenters. And APIs are the key to letting cloud data be sharable with mobile apps.

Clearly, app-centric “smart” phones and tablets and TVs and cars and watches and glasses are changing the way we go about our daily business. And APIs will power these smart devices by giving enterprise and Internet companies a way to push their data to apps. That hope of bridging the cloud with mobile is probably why Intel has kept its current API product intact. Mashery broadens Intel’s API scope by providing a way to not only share data with mobile apps but now also the developers that build these apps. But will this plan succeed?

If it does, it will take quite a bit of time. The reality today remains that Intel – even despite the semi-recent McAfee acquisition – is not oriented to selling software or even cloud services into the enterprise. It’s missing the sales force. It’s missing the history. And in many ways, it’s missing the rest of the software stack it needs to power the networking, infrastructure and application parts that underpin data in the cloud. That will make selling an API platform comprising a legacy API Gateway and newfound API developer platform a harder proposition. It’s kind of out there alone.

Another obvious roadblock to making the Mashery acquisition successful is that Intel’s existing API Gateway and the Mashery API service are designed for two very different audiences inside the enterprise, with un-reconcilable needs. The API Gateway is designed for an IT department that wants to run its API Management layer in its own datacenter. The Mashery offering is designed for a non-IT buyer (a mobile program manager, say) who wants to run everything in someone else’s cloud.

One is technical, the other is not. One is on-premise, the other is SaaS. One sells traditional software licenses, the other pure subscription. The first aims to address internal and external API integration challenges. The latter is only really concerned with the challenge of acquiring external API developers (though Mashery would probably protest this point).

Will the two be a marriage made in heaven? Given that the Intel/Mashery partnership is already a year old and that Mashery was barely able to grow its revenues in that time, the likelihood seems remote. But who knows for sure? And anyway, Intel has probably not bought Mashery for its $12M in revenue but for its long-term potential as a pathway to mobile.

January 28th, 2013

Growing Your APIs in the Amazon Cloud

Amazon Tech TalkPutting applications in the cloud can reduce overall IT costs and deliver greater scalability. Cost considerations are always a concern in IT infrastructures but scalability may be the most important benefit of hosting applications in the cloud. Leveraging the elasticity of Amazon’s cloud infrastructure can allow you to scale your APIs to match market demand. Amazon Web Services provides tooling that can help you be quicker to market with your APIs.

But do interfaces hosted on AWS and exposed to third-party developers contain significant vulnerabilities? Cloud services allow third-party access to applications and data through APIs. Failing to properly secure that access can put the data and applications at risk. So, how do you safely expose APIs in a cloud environment?

Understanding the cloud API model isn’t always easy. So, on January 29, we’re having a live discussion about publishing APIs in the AWS cloud, which may help answer questions surrounding exposing APIs in cloud environments. I’m excited to welcome Layer 7 Technologies Senior Software Developer Hirbod (Rod) Moshfeghi as our special guest for this API Tech Talk. This is a great opportunity to have your questions answered and to discuss the implications of publishing cloud-based APIs.

Here’s how to join the live discussion…

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

Submit your questions:

January 3rd, 2013

CES 2013 Panel: Privacy & Security in the Cloud

CES 2013The Consumer Electronics Show (CES) 2013 is starting in Las Vegas next week and cloud computing is on the agenda. You can be sure that a technology has moved out of the hype cycle and into everyday use when it shows up at a show like CES, known more for the latest TVs and phones than computing infrastructure. People don’t really need to talk about cloud any more; it’s just there and we are using it.

Of course there will always be a place for a little more talking and I’ll be doing some of this myself as part of the CES panel Privacy & Security in the Cloud. This discussion will take place on Monday Jan 7, 11am-12pm, in LVCC, North Hall N259. The panel is chaired by my good friend Jeremy Geelan, founder of Cloud Computing Expo, who honed his considerable moderation skills at the BBC.

I’m planning on exploring the intersection between the cloud and our increasingly ubiquitous consumer devices. We will highlight the opportunities created by this technological convergence but we will also consider the implications this has for our personal privacy. I hope you can join us.