Thursday, August 28, 2014

The Value of API Monitoring and Analytics

API Monitoring and Analytics are a very important part of API Management, because they answer question "Who is using my APIs", as well as providing the basis for monetization of APIs.

In the Axway API Management solution, we provide web-based monitoring of APIs both in real-time and as reports. In the screenshot below, we see API Analytic in action, with information about API usage, and the ability to generate a PDF report:


An example of a generated PDF report is shown below. Everything is customizable.


You can also search for specific transactions in Analytics using drop-down forms as shown below:



You then see all of the information about the API call, including the steps as it passes through the API Gateway:


You can also see the time for each step, as shown below. This is very important for diagnosing why an API call might be taking a long time. Using Axway API Management, you can see all the dependencies exactly, and do a full root-cause analysis. If someone says "My mobile app is running slowly", you can see exactly why that is (e.g. a back-end server is running slow). Notice the times for each step in the Gateway shown below:



In the Traffic Monitor, you can also see the times for requests and responses:



In addition, it is common to single out certain information from API traffic and use this within analytics. For example, your API calls may contain a field called "Waybill number". You can isolate the value of this field using JSON Path (in the case of JSON) or XPath (in the case of XML). Then, you log it as a "custom attribute" in Policy Studio as show:

Now that you've singled out this "Waybill number" as a specific attribute, you can then search for it explicitly.

You can also set what exactly is logged, if you want to log for tools such as Splunk to crunch the data.

Wednesday, August 13, 2014

Are REST APIs Inherently Insecure? - Speaking at ISC2 in Atlanta in October

REST security is a hot topic. One of the reasons for this is the continued blowback from the over-complexity of the WS-* specifications. These specifications,  including WS-Security, WS-Trust, and WS-ReliableMessaging, and were notorious for being difficult to comprehend. In fact, people wrote whole books about Web Services Security :-) . One of the benefits of REST is simplicity. But, on the flipside, the lack of standards for security has led to the proliferation of ad-hoc security approaches such as the use of API Keys. API Keys are frequently used for API "authentication" often without much regard for potential attacks such as replay attacks.

But, by using an API Gateway approach, is it possible to layer on security for REST APIs? Could they (shock, horror) co-exist with heavyweight WS-* style SOAP web services? I'll be talking about this topic in my talk on "Are REST APIs Inherently Insecure" at the ISC2 Security Congress in October in Atlanta. Hope to see you there?



Tuesday, July 22, 2014

ViewDS and Axway - PEP/PDP interop using XACML for externalized authorization

Andrew Sciberras, the man with the most impressive mustache in Identity (until he shaved it off!), has written a very useful post on how Axway and ViewDS interop together using XACML to enable external authorization for SOA and APIs.

The interop announcement, which coincides with the Cloud Identity Summit in Monterrey, speaks about how customers can now leverage ViewDS and Axway together in order to create complex authorization rules. An example of such a rule would be "Only the patient or their doctor can access a medical record, or the patient's parents or guardians if the patient is under 18 years of age". These types of policies are particularly suited to XACML.

The overall architecture is shown below:


Sunday, July 20, 2014

Video: Mobile App calling APIs, using the Axway API Portal and API Gateway

This week I am in Sydney, Australia, for Gartner AADI this Monday and Tuesday, then the Axway API Workshop here on Wednesday (still time to register if you're in Sydney!). The API Workshop ends with a wine reception, pitting French wines against Australian wines. In keeping with the theme, my colleague Charles Poulson and I have worked on sample APIs and apps, to see how an API Portal and API Gateway are used as the API backend for mobile apps.

In the video below, you can see a "Wine Chooser" sample Android app which consumes an API that's registered in an API Portal, and see the mobile API usage reporting being gathered and reported. We also see API Keys issued at the API Portal. Come along to the API Workshop on Wednesday to get your hands on the real thing! (the app and the wine :-) ).

video

Configuring OAuth for initial LDAP Authentication

Although OAuth is not for authentication (the "auth" is for authorization), it usually presupposes that an authentication event has taken place. In the case of the Axway API Gateway, you can use the internal use store for this authentication, or you can use a third-party repository like LDAP. If you want to switch to LDAP, you can simply choose a different authentication repository under "Validate credentials against this repository" in the OAuth 2.0 policies in Policy Studio as shown below:


If you want to add a new authentication repository, you can find these under "Authentication Repositories" in Policy Studio, as shown below:


Note that other options include CA SiteMinder, Oracle Access Manager, IBM Tivoli Access Manager, and others.

Friday, July 18, 2014

APIdentity at Cloud Identity Summit next week

My colleague Ross Garrett is speaking next week at the Cloud Identity Summit on the "APIdentity" track. "APIdentity" is a neat mashup of "API" and "Identity" - I like it. Catch Ross's talk at 2.10pm on Monday 21 July:
API Security for the Cloud: Tales from the Trenches
Cloud technologies and mobile devices are transforming interactions with organizations via APIs. APIs present an endless opportunity for businesses to generate revenue, engage customers and collaborate with partners; Gartner even predicts 50% of B2B collaboration will occur via Web APIs by 2016.
This API Economy creates new IT complexity and presents risks for businesses when not implemented and managed securely. This presentation will discuss examples of organizations securing APIs, examining the API security state of play for the cloud. Questions that will be answered include:
  • How are organizations implementing OAuth?
  • How are they Managing Keys?
  • What are real-world examples of API security?

Telstra Hybrid Integration Case Study next week at Gartner AADI Sydney

Next week I'm excited to be attending Gartner AADI Sydney, where the Axway sponsor session features Telstra's Richard King speaking about Hybrid Integration, at 3.15pm on Monday July 21. Hybrid Integration, and the Hybrid Integration Platform (HIP), are very exciting topics in integration at the moment. Connections between on-premises and Cloud services are enabled in this way, all through APIs.

Here is the preview of the talk:
Innovations in Cloud, Mobile, Social Media and Big Data are revolutionising how Telstra International goes to market to engage with their customers, employees and suppliers. Richard shares experiences of how the business addressed the challenges of legacy integration, governance and politics to implement a framework to mobile-enable enterprise applications and govern services across public, private and hybrid cloud environments. 
http://events.gartner.com/#/en/navigator/APIN20A/agenda/24353/sessiondetail/speakers-tab 
I'm looking forward to the session, and to catching up with so many partners, customers, and friends in Australia. Maybe not looking forward to the long flight so much though... :-)

Wednesday, July 9, 2014

SOA, ESB, TIBCO, and Axway API Gateway skills required in Maidenhead UK - Three UK Job Posting



Readers of this blog might be interested in this Systems Integration Solution Designer Job Posting from Three UK, located in Maidenhead which just outside of London.

Skills listed include: TIBCO ActiveMatrix, Axway API Gateway, and Enterprise Java, as well as knowledge of SOAP, web & RESTful services.

Tuesday, July 8, 2014

Why do some boarding passes say "API" on them?

Since I work in the API Management business, I always smile to see "API" on my boarding pass (well, as much as it is possible to smile when checking in for a flight). You can see "API" on the boarding pass for my current trip to Germany below:


But what does "API" mean on a boarding pass? The answer is that it stands for "Advance Passenger Information". It's information about passengers which is sent ahead of the flight, often for immigration/customs purposes, and for security of course.

However, there is in fact a link between this API and the "other" API (the Application Programming Interface). The Axway API Gateway is used to securely send API information between some countries. The API Gateway ensures that the data is formatted correctly, sent over an authenticated link, and is signed and encrypted. It's an example of an API where delivery of the data is absolutely essential, and this is assured by the API Gateway. So it's an "API for API" effectively :-)

Looking forward to the API Management & REST Security Workshop in Sydney - 23 July

I'm happy to say that later this month, on 23 July, we're holding an API Workshop as part of the Axway Connections event in Sydney, Australia. We'll be covering REST API Security (always a hot topic), plus Social Login (OAuth and OpenID), SalesForce and Office365 connections, and mobile API access. Registration for the API Workshop, part of the overall Axway Connections event, is free using this form. The API Workshop is located at the Pullman Hotel on Sydney Harbour, which has a nice view as you can see below:
Pullman Hotel - Sydney Harbor - Location for 23 July API Workshop
For those of you who haven't attended an API Workshop before, it's a great way to see API Management and security in action, and learn about technologies such as OAuth.

In addition, as part of the Axway Connections event, we have some great speakers lined up:

  • Ian Gibson, CIO at SuperChoice. Ian will be talking about the Superstream protocols (including ebMS v3 and AS4, which are you can read more about here).
  • Richard King, Head of IT Risk & Security at Telstra Global. Richard will be talking about hybrid integration in his talk on "Enabling a Digital & Cloud Future for Telstra Global"
  •  Chris Solomon, Integration Architect Middleware, will be presenting the New Zealand Customs Service case study
And I like the look of the finale at the end of the day :-)

The Old World meets the New World: Cheese & Wine Tasting
Join us for a fun-filled networking session where we conduct a tasting of some of the best vintage wines Australia and France have to offer whilst enjoying selected cheeses and canap├ęs. This final event is limited in numbers so please clarify when registering if you can, or cannot attend.

Registration for the event is free, via this form.

Wednesday, July 2, 2014

API Workshops roll on - Detroit / Connected Car - and next stop Munich June 10

Last Tuesday in Detroit, along with IC-Consult, Axway ran an API Workshop in Detroit. Many attendees from the major car companies were present. One of the big conversation topics was Social Login ("Login with Google", etc). This is something which we saw can be implemented using the Axway API Gateway, and in fact the API Gateway can be used to map from a Social Login to a local on-premises Identity and Access Management product like Oracle Access Manager (here's a description of the Google to Oracle OAM mapping in action). That allows for a hybrid Cloud/On-Premises identity approach.

Aside from Social Login, we also saw SalesForce.com integration, and the API Developer Portal in action. The highlight, though, was when Robert Foster from IC-Consult ran through the BMW Group Connected Car case study. Here you can see Robert showing a video clip of Pierce Brosnan (as James Bond) with an earlier incarnation of the connected car (the chase scene from "Tomorrow Never Dies"):


The API Workshop tour rolls on. Next up is the API Workshop in Munich next week - 10 July. Sign up for free if you're in the area and interested in API Security, OAuth, Cloud/Social Login, and all things API-related :)


Monday, June 30, 2014

How to associate a single API Gateway with multiple IP Addresses in a multi-homed environment

One of the neat features of the Axway API Gateway is the ability to deploy it in a multi-homed environment, so that it is associated with multiple IP addresses. The requirement is for a single API Gateway to listen on multiple IP Addresses, on the same port (usually the SSL port: port 443).

This is often done because an organization wishes to deploy API Gateways virtually in multiple places on the network, while using the same server to run the API Gateways.

To do this, the first step is to associate the multiple IP Addresses with the machine running the API Gateway. In this example, we associate two IP Addresses (with two corresponding subnets): 192.160.0.10 and 10.10.1.10. This is done at the OS layer.

Next, we use Policy Studio to setup our two listeners, corresponding to the two zones (which we'll imaginatively call "Zone 1" and "Zone 2"):




Note where the IP addresses are configured above. Users of the API Gateway might be used to seeing an asterix ('*') in the "Address" field under the port configuration. The asterix means that the API Gateway binds to every IP address available on the machine. By specifying the IP address in the "Address" field, we are saying that the API Gateway will only bind to this port for this listener.

Also notice above that both listeners are listening on the same port, which is the SSL port 443. Normally if you have two applications listening on the same port, there is a clash. But in this case, the API Gateway is listening on two ports on two different IP addresses.

Underneath our "Zone 1" and "Zone 2" listeners, we can associate different paths. So,  https://192.160.0.10/myAPI will be handled under the "Zone 1" listener.

Notice also that different certificates can be used for the different listeners. The certificates themselves can be generated using the Axway API Management solution (under "Certificates and Keys" in Policy Studio). If you have multi-homed your API Gateway to multiple addresses which are associated with multiple machine names (e.g. "apis.mycompany.com" and "internal.mycompany.com") then you can issue certificate within Policy Studio for these names, then load them using the "X.509 Certificate" button in the "Configure HTTPS Interface" screen above.

Happy multi-homing! There's no place like a (multi)home :-)