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 :-)

Friday, June 27, 2014

Monetizing mobile apps - Comments on McKinsey Report

McKinsey recently produced a report entitled "Monetizing mobile apps: Striking the right balance". It talks about how APIs can drive revenue for organizations. The report is certainly useful to further drive awareness of APIs, but there are some comments which I have on it.

The report focuses only on customer-facing mobile apps. But, organizations are gaining significant value by deploying APIs to enable employee apps (think of field-sales apps, or apps for employees working in the field installing products). Last week, we ran a webinar on Business-to-Employee Mobile Apps with Scott Matsumoto from Cigital where we ran a poll about what kind of apps which organizations are enabling through APIs. Customer-facing apps topped the poll, as expected, but look how important internal employee apps are:


I also think the McKinsey report suffers from some selection bias, by only examining Public APIs which are in the ProgrammableWeb directory. When organizations deploy private APIs or partner APIs, enabling mobile access in this way, they don't appear in ProgrammableWeb. These APIs may be paid for as part of a larger business service, or, for an Internal API, may be paid for within the organization as a cost center.

Manfred Bortenschlager makes some great points about this McKinsey report in his blog, writing:
"There are reasons not to pursue APIs, of course, starting with the desire of many companies to have more direct control over their data." 
?? APIs do give direct and manageable control about data. 
“But our analysis indicates that APIs are generating revenues in one of three ways for the companies that choose to contribute their data.” 
This analysis is apparently not very in depth. Simply looking at John Musser’s talks there is at least a dozen of business models for APIs. http://manfredbo.tumblr.com/post/90063148340/monetizing-mobile-apps-striking-the-right-balance
I was also waiting for them to mention John Musser's excellent analysis of payment models for APIs. Surely no analysis of API payment models is complete without even a reference to John Musser.

Also, to Manfred's point, an API Gateway is what is used by organizations to apply "direct control over their data" when they deploy APIs.

All in all, the McKinsey report is useful, but with the caveat of the comments above. Great to see so much awareness of the benefits of APIs across the board.

Tuesday, June 24, 2014

Prebuilt OAuth connectors for SalesForce.com

One of the neat things about the latest (v7.3) version of the Axway API Gateway is that it comes with pre-configured OAuth 2.0 connectors for SalesForce.com. You can find these under External Connections in Policy Studio, as shown in the screenshot below:


The advantage of this feature is that it means that users do not have to worry about the intricacies of OAuth, or the nuances of how OAuth is implemented differently by different identity providers (IdPs).

Using the prebuilt SalesForce.com OAuth 2.0 connector, it is quite simple to setup a connection to SalesForce.com and then take advantage of the Axway API Gateway's monitoring to provide visibility on your SalesForce.com usage: