Ronnie Mitra

Ronnie Mitra

Ronnie Mitra is an expert in enterprise development and integration who leads Layer 7’s API Architecture & Design Practice across Europe. In this role, Ronnie helps companies leverage their burgeoning API potential. Before joining Layer 7, he worked at IBM where he held the worldwide leadership role for WebSphere connectivity products.

January 30th, 2014

API Academy Summits

API Academy SummitsLast year, Mike Amundsen, Holger Reinhardt and I each traipsed around the world to bring API architecture guidance and advice to your home towns.  It was a lot of fun, we got to meet some great people and we had a chance to learn about the challenges that front-line API designers face. We also managed to earn a lot of air miles and give away a lot of t-shirts.

But this year, we wanted to top ourselves and do something bigger and bolder. So, instead of going out individually, Mike, Holger and I are getting together to dish out practical API design advice together in a series of API Academy Summits. I’m really excited about these events because we’ll have a chance to provide differing points of view and draw on our collective expertise to give you the best guidance possible. Our goal this year is to continue to go beyond the inspirational hype about why your business needs an API and go deeper, addressing the real challenges that people who actually have to implement API programs face in the real world.

In addition to the API Academy team, we are extremely pleased to have Forrester Research analyst Randy Heffner providing a keynote presentation. Randy has been a great source of API design information over the last year and if you’ve been reading his work, you’ll know he is all about providing great practical advice to API designers.

Our first Summit is taking place in London on February 6, closely followed by an event in New York city on February 13. These full-day events will include real API implementation stories from William Hill and L’Oreal as well as providing a mobile developer’s view of API design, courtesy of local London developer Niall Roche.

Last year, we were surprised to hear from API Academy workshop attendees that they wanted us to talk about Layer 7′s products. We want these to be vendor-neutral events but we’ve listened to the feedback and are trialing a short session introducing the Layer 7 API Gateway and Portal.  This session will be held at the end of the day and we promise not to lock the doors and force you to listen to the pitch!

So, if you have a chance to be in London on February 6 or New York on February 13, make sure you find time to join us for one of our API Academy Summits!

December 2nd, 2013

How I Lost Weight & Learned About APIs

How I Lost Weight with APIsTrying to stay in shape is one of those never-ending life battles that I’ve come to expect as I get older. I’ve bounced between being a healthy shape and a not-so-healthy one for years and I’ve managed to live life just outside the edge of ideal fitness. A few months back, I reached an apex point and dedicated myself to losing a few pounds (again) and set off on a journey to change my life (yet again). Little did I know I’d learn something about APIs along the way.

Everyone has their own way of losing weight but I’ve always preferred a measurable, rationalist approach: I count the calories I consume, I subtract the calories I burn and I budget accordingly. The nice thing is that this method forces me to think about what I’m consuming and what I’m doing. The massive downside is that keeping track of all of the data is a monotonous and soul-destroying effort that often leads to me giving up.

Of course, there is an app for everything now and I started using  a tool to keep a log of foods that I ate along with their associated caloric burdens. One problem with this type of tool is that, while it’s easy to log consumption of food using features like bar code scanners and crowd-based data, the process of logging exercise and calorie expenditure is entirely manual. This can make fitness goals harder to achieve as users like me end up either under or over estimating their daily calorie burn.

Thankfully, devices to monitor your physical exertion do exist and they are reasonably affordable. These are wearable devices that provide a tally of steps taken, stairs climbed and physical exertion throughout the day, providing a wealth of personal data to mine. To be honest, I’d always viewed these devices in the same category as things like Google Glass – really cool pieces of technology that bleeding-edge enthusiasts wear publicly at the cost of their own dignity. But something changed for me when I realized that I’d be able to connect the calorie-counting app I was using with the wearable fitness device. So, I made a purchase.

By connecting the food-tracking application with the activity-tracking device, I was able to get a much more accurate picture of my caloric budget for the day. The systems integrated remarkably well and the quantification of remaining calories along with a few gamification features provided extra incentive for me to keep moving and eat less.

In the end, this behavioral conditioning of triggers, alerts and feedback loops worked well for me and I was able to drop a few pounds. Of course, I lost the tracker on an airplane about a month in and I’m currently racing back towards a pear shape but that isn’t the point. What is more interesting is what we can learn about integration from my journey:

1.  An API is a Great Way to Extend Customer Reach to Platforms
When we think about building APIs, we usually think about extending out to mobile devices or social platforms. But organizations should consider how their products can be extended to niche and non-traditional platforms that their target user base actively uses. If the wearable tracker I purchased didn’t work with the calorie-counting application I was already using, I never would have considered buying the tracker in the first place. But thanks to the API-based integration, I could visualize myself using it and this was the trigger that resulted in a purchase decision.

2.  Integration is Becoming a Core Requirement Instead of a Feature
Something I noticed when scanning the forums on the tracker device’s Web site was the number of posts related to integration with other exercise platforms. For this user base, integration with their favourite run-tracking, calorie-counting or fitness-gamification tools isn’t just a nice-to-have – it is the minimum expectation. It seems that end users are increasingly expecting product vendors to support their platforms of choice and want the freedom to make their own decisions. In other words,  users don’t want to be punished for choosing a less popular tracking tool or a mobile phone operating system that has less market share.

3.  Integration with Potential Competitors can Pay Off
What I didn’t mention in my story was that the fitness tracker I purchased did come with a calorie-consumption-tracking feature. In fact, part of the revenue stream for this product is the sale of subscriptions to the manufacturer’s fitness portal, as part of an end-to-end fitness management program. This means that supporting out-of-the box integration with other fitness trackers actually comes at a potential revenue cost for the tracker vendor. But I would imagine that the overall revenue benefit from attracting customers like myself outweighs the revenue lost from users who choose not to subscribe to the portal. Integrating with competitive products can be a risky proposition but a smart gamble can really pay off.

As interest in the Internet of Things (IoT) continues to increase, I expect to see an increasing variety of interesting device-to-platform integration stories. Businesses will need to have coherent business strategies for extending to this new world, with APIs as an important supporting action.

Also, if you happen to see me in person, don’t forget to tell me how great I’m looking nowadays.

October 4th, 2013

Can Your API be BREACHed?

Secure APITLS and SSL form the foundations of security on the Web. Everything from card payments to OAuth bearer tokens depend on the confidentiality and integrity that a secure TLS connection can provide. So when a team of clever engineers unveiled a new attack on SSL/TLS – called BREACH – at July’s Black Hat conference, more than a few eyebrows were raised. Now that it’s Cyber Security Awareness Month, it seems like a good time to examine the BREACH threat.

There have already been a number of articles in the technology press identifying threats BREACH poses to traditional Web sites and suggesting ways to mitigate the risks but it is important for us to examine this attack vector from an API perspective. API designers need to understand what the attack is, what risks there are to Web-based APIs and what can be done to mitigate the risks.

The BREACH attack is actually an iteration of  a TLS attack named CRIME, which emerged last year. Both attacks are able to retrieve encrypted data from a TLS connection by taking advantage of the way data compression works in order to guess the value of a confidential token in the payload. While CRIME relied specifically on exploiting the way TLS-based compression works, the BREACH exploit can target messages sent with compression enabled at the HTTP/S level, which may be much more widely enabled in the field.

HTTP compression is based on two compression strategies for data reduction: Huffman coding and LZ77. The LZ77 algorithm accomplishes its goal of data compression by identifying and removing duplicate pieces of data from an uncompressed message. In other words,  LZ77 makes a message smaller by finding duplicate occurrences of data in the text to be compressed and replacing them with smaller references to their locations.

A side effect of this algorithm is that the compressed data size is indicative of the amount of duplicate data in the payload. The BREACH attack exploits this side effect of LZ77 by using the size of a message as a way of guessing the contents of a confidential token. It is similar in nature to continually guessing a user’s credentials on a system that provides you with unlimited guesses.

While the premise is scary, the good news is that the BREACH attack doesn’t give an attacker unfettered access to the encrypted TLS payload. Instead, it is a targeted attack that attempts to retrieve a confidential token through repeated and iterative guesses. In fact, the attack isn’t an exploit of the TLS protocol at all, rather it is an attack that can be applied to any messaging system that uses the gzip compression algorithm (which is a variation of LZ77).

On top of this, BREACH is not an easy attack to pull off. A would-be BREACHer must:

  1. Identify an HTTPs message which has compressed data, a static secret token and a property that can be manipulated
  2. Trigger the application or server to generate many such messages in order to have a large enough sample size to iteratively guess the token
  3. Intercept all of these messages in order to analyze their sizes

Each of these requirements is non-trivial. When combined, they greatly reduce the attack surface for a BREACH attack in the API space. While API messages certainly contain data that may be manipulated and while many APIs do provide compressed response data, very few of those API messages also contain confidential tokens.

But designers of APIs shouldn’t dismiss the possibility of being BREACHed. There are at least two scenarios that might make an API susceptible to this attack vector.

Scenario 1 – Authentication & CSRF Tokens in Payloads:
Many APIs return an authentication token or CSRF token within successful responses.  For example, a search API might provide the following response message:

<SearchResponse>
    <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
    <Terms>…</Terms>
    <Results>…</Results>
</SearchResponse>

If this response message was compressed and the attacker was able to coerce a victim into sending many requests with specific search terms, it would only be a matter of time before the AuthToken credential was retrieved.

Scenario 2 – Three-Legged OAuth:
APIs that support the OAuth 2 framework for delegated authorization often implement CSRF tokens, as recommended in the OAuth 2 RFC. The purpose of the token is to protect client applications from an attack vector in which a client can be tricked into unknowingly acting upon someone else’s resources (Stephen Sclafani provides  a better explanation of the CSRF threat here.)  Due to the fact that CSRF tokens are reflected back by the server, the three-legged OAuth dance becomes a possible attack surface for BREACH.

For example, an attacker could coerce a victim to send repeated OAuth 2 authorization requests and utilize the state parameter to guess the value of the authorization token. Of course, all of this comes with the caveat that the OAuth server must be compressing responses to become a target. The fact that a new authorization code is generated for each authorization attempt would make this attack less practical but still theoretically possible.

Ultimately, the simplest way to mitigate the BREACH attack is to simply turn off compression for all messages. It isn’t hard to do and it will stop BREACH dead in its tracks. However, in some cases, designers may need to support compression for large data responses containing non-critical information or because they are supporting platforms with low bandwidth capabilities.  In these instances, it makes sense to implement a selective compression policy on an API Gateway.

While disabling compression will certainly negate the impact of the BREACH attack, a more general solution is to impose smart rate limiting on API requests. This will not only negate the sample size that a BREACH attacker needs to guess data, it will also stop other side-effect attacks that don’t rely solely on compression. In addition, log analysis and analytics will make it easier to spot any attempt at an attack of this kind.

An API Gateway is the key component for this type of security mitigation in the API space. A Gateway can provide the level of abstraction needed to enforce configurable compression and rate limiting policies that server side developers may not have the security background to implement effectively. In addition, the Gateway acts as a central enforcement point for security policy – particularly useful in larger federated organizations.

TLS is core to most of the security implementations that have evolved on the Web, including the OAuth 2 framework. This latest published attack does not render the world’s TLS implementations useless but it does introduce an interesting attack vector that is worth protecting against in the API domain. Remember, API rate limiting and usage monitoring are useful for much more than just monetizing an API!

September 30th, 2013

Workshops, Workshops, Workshops!

Layer 7 API WorkshopsOne of the great things about my job is that I get to travel around the world sharing API design strategies, experiences and theories with people who are at the forefront of our industry. These interactions not only make it easier to design effective APIs, they also have the potential to spark ideas that can lead to real business transformation.

But we aren’t all lucky enough to get these types of opportunities and it’s often difficult to justify the cost of traveling to far-flung events in the modern business world. If you’re in that boat, then it’s your lucky day: our Layer 7 API Strategy Workshop series aims to bring all the experiences, discussions and networking opportunities practically to your doorstep.

Over the next two months, Mike Amundsen, Holger Reinhardt and I will be delivering a series of free workshops on API strategy, the principles of good API design and the keys to designing an API that will last. In addition to core aspects of effective API design, we will discuss the emerging trends of developer experience (DX), the Internet of Things (IoT) and DevOps as they pertain to the API universe.

Our tour kicked off in September with great events in San Antonio and Los Angeles and it will continue through October and November with the following stops:

It’s going to be an exhausting couple of months for us but we’re looking forward to having some great conversations with our attendees. So, come out and join us during what promises to be a very thought-provoking and engaging series of half-day events.

September 13th, 2013

Nordic APIs

Nordic APIsIt looks like the remainder of September will provide a bounty of learning opportunities for those of you interested in diving deeper into API design.  To start with, Mike Amundsen and I will be continuing our Layer 7 API Academy workshop tour in Montreal and Calgary. In addition to our API Academy events, Mike will be hosting his annual conference related to all things REST with RESTFest 2013. I had the pleasure of attending last year and I highly recommend going if you are interested in thought-provoking conversation and ideas in the hypermedia domain.

On the other side of the ocean and closer to home for me is next week’s Nordic APIs conference in Stockholm (September 18-19).  I’ve been to a few of the smaller API design conferences that the Nordic APIs team has put on and I can say without a doubt that this will be a conference worth attending.  They’ve always done a great job of putting together sessions that will appeal to developers on the leading edge of API design as well as those who are looking for practical solutions.

I’ll be delivering a keynote presentation on a developer experience (DX) oriented design approach for APIs. My colleague Holger Reinhardt will be talking about the Internet of Things and Aran White will be delivering a demonstration of the Layer 7 product line. Of course, the great value in events like this comes from the serendipitous conversations that take place outside the agenda and Holger, Aran and I are really looking forward to swapping war stories with Nordic API attendees.

While I’m sad that I won’t be able to join Mike at RESTFest this year, I’m overjoyed at the reason I can’t go. I’m continually amazed at how much the European API design community has grown and watching the Nordic event grow from a few small events into a major conference has been eye opening. Not too long ago, it was difficult to find API design events to attend but now we are spoiled for choice. It’s a great indication of the continued interest in and growth of Web-based APIs.