Friday, August 28, 2015

Test and Protect your APIs - Smartbear and Axway webinar on Sept 10

This week, Axway released our plug-in for the Smartbear Ready!API testing tool. The plug-in provides integration between Ready!API and Axway's API Management solution. 

As part of the launch, we're also running a joint webinar on September 10th, where we will discuss the two sides of API Security - testing and protection. The webinar includes a demonstration of API Security in action: both the testing (Smartbear Ready!API Secure) and the protection (Axway API Gateway). We'rerunning the webinar twice on the day, to accommodate different timezones. 

Here are some of my thoughts before the webinar:

Is API Security new?

 The API Economy has taken off in recent years, and it is tempting to think that API Security is a new thing. But it has a long history. Security of SOAP APIs has, of course, an infamous history involving many WS-* standards (some of us wrote whole books on these :) ). SOAP/XML attacks like the XML Bomb keep coming back to haunt developers. However, REST has a longer history than people realize. Way back in 2003, Jeff Barr in Amazon, famously pointed out that only 15% of Amazon Web Services traffic is SOAP based, and [here comes the pun] the rest is REST. Both types of APIs had to be secured.

At the RSA Conference in 2006 (almost 10 years ago, yikes!), I gave a talk on REST Security, when much of the discussion was about "pure" versus "practical" REST. Mobile then became a driving factor in how APIs are used, creating facts-on-the-ground that moved us on from much of the theoretical discussion.

How important is API Security?

API Security is very important. Everyday users may think "I never call APIs, only developers do that", but the reality is that mobile apps and IoT devices call APIs regularly. And this is where API security issues manifest. Let's look at what two researchers have found with API Security for mobile and IoT:

On the mobile front, Troy Hunt's influential "Hack Your API First" article and training makes it clear that much of mobile security is actually really API Security. As Troy explains, if you want to probe an app's vulnerabilities, a good way to start is to see how it calls APIs. If you have your app use a proxy (simply by changing your phone's connection settings), and then by running a tool like Fiddler, you can often see very obvious security vulnerabilities. 

On the IoT front, Randy Westergren has shown how IoT devices can call APIs in insecure ways. These APIs calls become the vulnerability. In this case, a security layer was needed in front of the APIs to protect them. An API Gateway fits the bill. My colleague Rob Meyer has talked about how Just-In-Time principles can be applied to DevOps testing, remarking that "Testing is the Andon cord of DevOps" (don't know what "Andon cord" is? I highly recommend checking the article). 

So, on the API Security webinar on September 10, I'm looking forward to a great discussion about the two sides of API Security - testing and probing for vulnerabilities (the "sword") and protection (the "shield"). See you there!

Tuesday, August 25, 2015

Is an API Portal a Wiki of APIs?

Last week I spoke at the Integration Developer News SOA & API Summit on the topic of "How APIs are Driving Digital Transformation". You can still view the recording (as well as the talks by IBM, Oracle, Red Hat, and Neuron ESB) on the SOA & API Summit event page.

One of the questions which came up, from a view at a large system integrator, asked is an API Portal "more of Wiki of all the APIs?". This is one of the questions where the answer is "Yes, and....". So, let me answer it in this blog post.

An API Portal is the place where developers go in order to get all the information they need to use an API. Developers using the API can contribute to the content (usually through a wiki or forum or blog), as can the developers of the API itself. The actual API itself is shown at the API Portal using what is often called "active documentation", where developers can drill into the API definition in a Swagger interface, and perform "Test in place" testing to ensure they are using the API correctly.

To show this in action, here's some screenshots of the Axway API Portal. Of course, when customers deploy the API Portal, it is re-skinned (think "Acme API Portal"), but here is it in its Axway-branded incarnation. In the screenshot below, we see active documentation of a SOAP API (yes! the Axway API Portal can be used for SOAP as well as REST).

Here's a REST API below, shown in the API Portal. Notice the "Try it out!" button at the bottom, to try out the API. You can also see all the information needed to call the API (the model schema on the right):

For those who prefer it, API documentation is also a provided at the API Portal in PDF format, including SDK information and info on how to access the API from Android or iOS:

Finally, many APIs have a monetization model, as explained by this seminal presentation by John Musser. As well as learning how an API is used, it's important that the developer using the API also understands the costs of the API. This monetization is supported by the API Portal as pricing plans. We see some of these shown below.

So, in answer to the question from the SOA & API Summit, an API Portal is more than just a wiki for an API. It includes active documentation, forums and blogs, in-place testing, and monetization info. 

Thanks for the question - and keep them coming!

Tuesday, August 18, 2015

SOA & API Summit online this Thursday - with Axway, IBM, Oracle, Red Hat, Neuron ESB

This Thursday, August 20, I'm participating in the SOA & API Summit which is a online event run by Integration Developer News. I'm talking about how APIs are driving digital transformation. I always recommend this event because it mixes a lot of viewpoints, with speakers coming from the new API world, mixed with speakers coming from the older ESB world. It also features a lot of Q&A related to digital themes, driven by Vance McCarthy who always has insightful comments and questions, as well as questions from attendees. You can still register online - hope to see you there!

Friday, August 14, 2015

Identity Bridge - How to use an API Gateway to bridge between X.509 Certificates, SAML, JWT, and OAuth Access Tokens

When integrating systems together, identity mediation can be just as vital as protocol mediation. Consider a situation where a user is authenticating with an X.509 certificate. The X.509 certificate could be an iOS certificate stored on an iPhone, or could come from a CAC/PIV card issued to a US Government employee. When the user is accessing a system that requires a SAML Assertion, how can that X.509 certificate be converted to a SAML Assertion?

The answer is an Identity Bridge. This term, originally coined by Mark Diodati who is now a Gartner analyst, is used to describe a service which converts identity tokens between domains, enabling seamless access. An API Gateway such as Axway's is an ideal tool to use as an Identity Bridge, because of the fact that it supports a wide variety of identity tokens. 

With my colleague Daniel Wille, I've put together a video which shows the Identity Bridge scenario whereby a user is authenticated via one token type (in this case an X.509 Certificate) and then the API Gateway bridges to other tokens, specifically:

  • How to convert to an OAuth JWT
  • How to convert to an OAuth Access Token Token
  • How to convert to a SAML Assertion (containing attribute statements)
A REST API at the API Gateway is used to do the identity bridging (e.g. requesting an OAuth Token based on the initial X.509 token).

For more information, and to get a copy of the API Gateway to perform your own Identity Bridging, check out the Axway site.

Wednesday, August 5, 2015

Return of the XML Bomb

The XML Bomb is an attack which has a long history, which I've documented back in 2009. Today in 2015 it continues to be a cause of concern. As with many security vulnerabilities, perhaps the evocative name helps. I'm happy to say that our API Gateway blocks the attack, and has done for many years.

So how does the XML Bomb work? It's a clever attack and well worth examining:

Older types of APIs use XML, which can be defined using a Document Type Declaration (DTD). DTDs are an old technology now (actually originating in SGML) and largely superseded by newer technologies (XML Schema, JSON Schema).

The issue is that DTD implementations can be vulnerable to recursion attacks. The SOAP specification states “A SOAP message MUST NOT contain a Document Type Declaration” ( Section 3). However, some XML applications process DTDs, and therefore products which protect XML applications must block DTDs.
The following DTD contains a recursively defined entity “&x100;” which would be expanded into the huge amount (2^100) repetitions of the string “hello” by any XML 1.0 standard compliant parser. This would cause excessive memory usage and/or excessive CPU usage:

<!DOCTYPE foobar [
<!ENTITY x0 “hello”>
<!ENTITY x1 “&x0;&x0;”>
<!ENTITY x2 “&x1;&x1;”>
<!ENTITY x3 “&x2;&x2;”>
<!ENTITY x4 “&x3;&x3;”>
<!ENTITY x98 “&x97;&x97;”>
<!ENTITY x99 “&x98;&x98;”>
<!ENTITY x100 “&x99;&x99;”>

It's important to ensure that your APIs are not vulnerable to this attack. An API Gateway is a great way to achieve this.