Wednesday, April 23, 2014

Logging and reporting custom variables in Axway API Analytics

API Analytics is important to solve what is sometimes called the "Cinderella Problem". i.e. "Who's been using my APIs?". As well as monitoring your APIs, you often need to look into the API traffic itself, and pull out custom variables such as Customer IDs. These variables could come from within JSON (using the JSON Path filter to read it) or perhaps from the contents of a parameterized URL. One of the neat features of Axway's API Gateway and API Analytics is that you can configure a custom variable to be logged, for viewing in API Analytics. See below for a screenshot of how this is configured:


Wednesday, April 16, 2014

Healthcare Webinar today - Enforcing HIPAA Policy on Cloud Services

I'm presenting a webinar today at 2pm Eastern / 11am Pacific on "Enforcing HIPAA Policy on Cloud Services". Covering services such as SalesForce and Amazon, but also something we see a lot at Axway now: Sharepoint as a hosted service.

Still time to register - here's the link: http://www.axway.com/events/event/webinar-enforcing-policy-cloud-services


Heartbleed mitigation for Web APIs - Catalog your APIs, and apply a Gateway control point

Gary Oliffe at Gartner has an insightful blog post today about how the Web API angle for Heartbleed has been largely ignored. It reminds me of the DoS attacks on banks this time last year. Everybody seemed to focus on the banking websites which were brought down, but not on the Web APIs which also suffered (and rendered some banking apps unresponsive). People naturally focus on what they can see - websites - not on what they can't see - Web APIs.

Gary writes:
With all the media coverage of Heartbleed over the last few days it occurred to me that there has not been nearly enough coverage given to the impact of Heartbleed on web APIs, both from the perspective of a consumer and provider.
http://blogs.gartner.com/gary-olliffe/2014/04/16/heartbleed-hit-your-apis-too-manage-those-dependencies/
He goes on to talk about how an inventory of the APIs you use (internal and external) is vital, writing "You need to know the services are you using, the services are you providing, who is using them, what you and the other party need to do to protect yourselves and whether it has been done". 

I couldn't agree more. The first step to managing your APIs is to catalog them. I've written before about the importance of the API Catalog, both for consumers (in an API Developer Portal) and also for administrators to keep track of the APIs which they are managing. With Axway, the API Catalog itself is available as a Web API (using JSON), which can be customized.

Complimenting the API Catalog is the API Gateway. An API Gateway is especially important for responding to Heartbleed because it provides a control point where you can perform virtual patches. If clients are accessing APIs via the API Gateway, that is the point where you ensure that security rules are applied. An API Gateway provides a level of virtualization in front of the actual APIs themselves, providing a point to quickly respond to issues such as Heartbleed.

So, the combination of (a) an API Catalog, providing an inventory of APIs your organization uses, and (b) an API Gateway to enforce security rules and apply "virtual patches", is important to deal with security events such as Heartbleed.

Thursday, April 10, 2014

Heartbleed

Once again Kin Lane nails it, saying that the response to the Heartbleed OpenSSL vulnerability says a lot about a company:

I'm happy to say that the Axway support team has reacted extremely fast to Heartbleed, producing support notes for Axway's many products which I am equally happy to say are not affected by the vulnerability. This includes the API Gateway, formerly known as the Vordel Gateway. Just take a look at the screenshot of the Axway support portal below, to see all the new Knowledge Base articles about Heartbleed. And if you're a customer, login and check all the Knowledge Base articles at support.axway.com.


Friday, April 4, 2014

Another API Breach - this time Tesla

Vincent Papaleo in Belgium's L'Echo has written an article this week about the API breach discovered in Tesla's API ("On peut hacker une Tesla!"). This is just one in a series of recent API vulnerabilities, following Snapchat and Buffer and others, but is the first to apply to an Internet of Things case.

The good news is that there is a solution: Secure your API. The recommendations for protecting APIs from attack still apply: Apply API throttling and quotas, adopt a "Deny by Default" posture for your APIs, have full visibility of your API usage, and get alerts on anomalies. This isn't the last API vulnerability story we'll see. As we said at the time of the Snapchat API breach: Don't let your API be next.

Tuesday, March 25, 2014

Going Dutch - upcoming Cloud and API events in the Netherlands over the next 10 days


Shortly I'm departing for the Netherlands for three events - hope to see you at one or more of these:

Thursday 27 March:
I'm speaking at the API Strategy event in Amsterdam as part of the Security and Testing panel, with folks from Intel/Mashery, WS02, and Twobo.  Looking forward to some good discussion on API security and API testing.

Tuesday 1 April:
I'm speaking at the Cloud Security Alliance SecureCloud event, also in Amsterdam. My talk is on protecting your Cloud APIs from Denial-of-Service. Look like some great sessions there from Coca Cola, from telecoms providers including BT and Belgacom, and from many governments.

Thursday 3 April:
Along with Simon Redfern from the Open Bank Project and Menno Abbink from Essent, I am speaking at the API Workshop event in Utrecht. We'll be covering hand-on examples of connecting to SalesForce APIs, OAuth 2.0, and developing an Android app to use APIs - more info in this blog post yesterday.

Monday, March 24, 2014

API Workshop in the Netherlands, April 3 - with Essent, Open Bank, and Axway - Covering Mobile, OAuth, Cloud

Following our recent API Workshops in Australia and New Zealand, the next port of call is The Netherlands, where we are running an API Workshop on April 3 in Utrecht.

For people who haven't been to an API Workshop, here's a quick description of the format: It's a half-day event, beginning with presentations by real live API practitioners speaking about the experiences. Following these presentations and Q&A, we then look at the technology behind APIs. At the Netherlands event, I'm very pleased to say that we have two great speakers lined up:

Firstly there is Simon Redfern from the Open Bank Project. I've followed the innovative work of the Open Bank Project for a while now. Here's a great introduction to their work by Tom Groenfeldt at Forbes. Simon will be speaking about how APIs enable a bank to operate as a platform.

The second speaker is Menno Abbink from Essent (largest electricity utility in the Netherlands). Menno has deployed APIs in the Cloud, on Amazon Web Services, and in fact shared the stage with Werner Vogels (CTO at Amazon) to speak about them at last year's AWS Summit in Amsterdam. Menno gave a fantastic talk at our last API Workshop in Brussels, covering APIs for household electricity usage and electrical vehicles. At the API Workshop on April 3, Menno is speaking about "Cloud to Ground integration", linking from APIs in the Cloud to an on-premises ESB. Here is a great introduction to Menno's work in this profile by Jan Stafford at TechTarget.

So it really is a privilege to have such great speakers lined up for the API Workshop. Following their talks, we'll then enter the "workshop" part of the API Workshop. We will be looking at how to deliver some of the technologies which they cover - including Cloud-to-Ground integration (bridging using the SalesForce API), security for APIs (technologies such as OAuth 2.0 in action) and mobile (walking through how to build a mobile app accessing APIs which are exposed through an API Developer Portal). We'll also see HTML 5 WebSockets in action. Register for the API Workshop for free here, or click on the "Register Now" button below.



API Workshop, April 3, 2014 - Hotel NH - Utrecht - From 9:30 to 13:00

Speakers:

- Simon Redfern: CEO of TESOBE and founder of the Open Bank Project | "Bank as a platform, transparency as an asset. How the Open Bank Project enables an innovation ecosystem".

- Menno Abbink: Senior Enterprise Architect, Essent 
 | 
“Powering the Hybrid Cloud – How APIs enable Cloud to Ground IT Integration”


Mark O'Neill : VP Innovation, Axway. Former Vordel co-founder  | “Designing Secure APIs for B2B, Cloud, and Mobile"

Technical API Workshop:
 
·         Practical workshop walk-throughs showing how and why you can leverage and manage APIs as part of a strategic enterprise engagement strategy:
o    Understanding REST API Security - How to secure REST APIs: Where do OAuth 2.0 and API Keys fit in?
o    Deploying an API Developer Portal - Developer management, API Catalog, and self-registration for developer groups
o    Mapping Cloud identity to enterprise identity - How to enable Single Sign-On with Google ("Cloud Login") via APIs
o    See HTML 5 WebSockets in action for real-time web data - Full duplex streaming of data, for next-generation Web APIs
o    OAuth 2.0 to Microsoft Office365 and OneDrive - How to bridge identity to Microsoft Cloud services 
o    Design and deploy an Android mobile app using APIs  - Java walk-through of the process of calling mobile APIs


Registration is free, so...


API Workshop:

Keynote speakers:


Simon Redfern
CEO of TESOBE and founder of Open Bank Project
openbankproject.com

Menno Abbink
Senior Enterprise Architect,
Essent



Mark O'Neill
VP Innovation - Axway
(co-founder, Vordel, acquired by Axway)

Date:
3rd April 2014

Location :
Hotel NH - Utrecht
Jaarbeursplain, 24
3521 AR Utrecht
The Netherlands

Time:
09:30 - 13:00 (cocktail lunch)

Tuesday, March 18, 2014

Innovator spotlight: Essent using APIs to enable a Self-Service Portal and Mobile Apps, powered by Axway

Essent is the largest energy company in the Netherlands, and has a significant API deployment which powers a self-service portal as well as mobile apps. At our Axway API Workshop recently in Brussels, Menno Abbink, Senior Enterprise Architect in the CIO office at Essent, spoke about how their API program.

I'm pleased to say that now we are spotlighting Essent's API innovation in a case study on the Axway website. The case study is a free download, and here is an excerpt:
Today, Essent’s two million customers can manage their utility contracts online using the Customer Self-Service Portal. The portal contains about 140 web services, providing an end-to-end self-service capability.
The underlying web APIs can be reused as needed for other applications, enabling Essent to react quickly to market trends and launch its own marketing campaigns. Taking advantage of this, Essent runs a multitude of web-based apps for its marketing activities, all of which can use the same “API backplane” enabled by the Axway API Gateway.
“Four mobile applications are available within the iTunes App Store and Google Play,” said Abbink. “These apps use Axway API Gateway as a secure environment in which customers can log onto the back-end systems to retrieve and modify their information." 

http://www.axway.com/resource-library/case-study/essent
This is a leading-edge API deployment, which I encourage anyone interested in large scale API delivery to check out.

Update: Menno Abbink is speaking about Essent's API deployment at the API Workshop event in the Netherlands on 3 April. It's a free event so register if you're going to be in the area.

Tuesday, March 11, 2014

How to call an API which uses a Self-Signed Certificate, using the Axway API Gateway

The Axway API Gateway, as the name suggests, is often used as a gateway in front of APIs / Web Services. The connection to the API behind the API Gateway often is over SSL. If this connection uses a self-signed certificate (i.e. not VeriSign or another global CA), then how do you configure the trust for this connection?

The first step is to import the certificate into the "Certificates" section of Policy Studio. To do this, click on the "Create/Import" button, which you can see on the bottom of the screenshot below:



Once you've imported the cert, then you need to use it in a policy. In the example below, I have a simple routing policy which will route to a backend server over SSL. The first step is to use a "Static Router" filter in order to enter the backend server name (in this case "dev.company.com") and select the radio button which specifies that I'm connecting over SSL:


I then follow this with a "Connection" filter, and I make sure that the certificate which I imported earlier is checked under "Trusted Certificates", as shown below:


Now, I apply this policy to a path off the API Gateway. Because this policy applies to any relative path, I can call a path like "/myAPI" or "/myOtherAPI" on the API Gateway, and it will be routed to the backed server using the same path. That is all you need to do to connect to an API / Web Service over an SSL connection which uses a self-signed certificate. 

Friday, March 7, 2014

Cross-Domain Security: Not only for government anymore

Next Tuesday, March 11, there is another chance to catch the GovInfo Security webinar on "Solving the Identity and Access Problem Across Domains".

Although cross-domain security is often associated with government, it's also very relevant for other verticals such as healthcare. In healthcare for example, it's often important to use standards such as SAML to convey identity or attribute info across domains, while having privacy safeguards in place.

The webinar covers the role of the Gateway as an "Identity Bridge", which is an important architectural design pattern used to map identity and attributes across domains, taking into account the different security and identity technologies that may be used (SAML, Kerberos, OAuth, or proprietary tokens like SiteMinder or Oracle Access Manager).

Thursday, March 6, 2014

Two job postings for Axway API Gateway experts - one in Phoenix and one in New York City

Here are two new job postings looking for Axway API Gateway (Vordel) skills, one in Phoenix and one in New York City:


New York or Phoenix? Take your pick...


Wednesday, March 5, 2014

APIs - the Global Angle

I'm writing this from Sydney Airport, having just rounded out our seven-city Axway API Workshop tour of Australia and New Zealand, and gearing up for the world's longest commercial flight (Sydney to Dallas).

If there was any doubt that APIs are a global phenomenon, just take a look at the attendances the Axway API Workshops over the past 10 days. At Wellington yesterday we had to commandeer a breakout room because of the large audience, who were treated to Ben Kepes and an API case study from the New Zealand Customs Service. In Melbourne I watched the excellent presentations from ANZ Bank and Infosys from the "standing room only" area, seeing many nodding heads and ipad note-takers in front of me. Here is Peter Jarman from Infosys explaining "Why an API Gateway":



This tour makes me cast my mind back to last month, when I spoke with Mark Boyd (an Aussie in Barcelona) about the global nature of APIs. One of the interesting things is that an API is particularly suitable for organizations which address a global market. In a global environment, you require an API Portal which enables developers to self-register at any time of the day or night. It is not acceptable anymore to say to a developer "we only support you in business hours in one timezone". As Mark Boyd put it:
For businesses in markets like Australia and New Zealand and in the Nordic countries, public APIs enable greater participation in a global business marketplace, removing the barrier of time differences that in the past created delays to global business partnerships.
http://blog.programmableweb.com/2014/02/21/private-partner-or-public-which-api-strategy-is-best-for-business/
This global nature is one of the great values of APIs, and something especially to think about after talking to so many API practitioners on this Axway API Workshop tour of Australia and New Zealand over the past 10 days. I will have plenty of time to think about it as I board my transpacific flight now... ;-)