Tuesday, April 24, 2012

Calling a REST API from an Android App, then converting to SOAP

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

A popular usage of the Vordel Gateway is to take a legacy SOAP service, and deploy it as a REST API for consumption by mobile apps. Mobile apps can consume REST APIs, but you are unlikely to call a SOAP service from a mobile app. REST-to-SOAP conversion is very simple to achieve using a Gateway, because the Gateway can expose REST APIs which map to SOAP services, dynamically creating the SOAP request based on the REST API call.

In the video below, you can see an Android app running in the Android emulator, which is calling a REST API on the Vordel Gateway. At the Gateway, you can see the REST API request is being dynamically converted to SOAP. All without writing any code :-)


video

When you zoom in, you can see the steps which convert the REST API to the legacy SOAP service call:



Tuesday, April 10, 2012

Mashing up the SalesForce API with CDYNE's EmailVerify API

One of the neatest things about the standard Vordel evaluation/training VM is that it ships with an mashup of the SalesForce API with CDYNE's EmailVerify API. This example Vordel Gateway circuit is run from a simple Web form, which is shown below. It is based on a scenario where an organization has an existing internal CRM, and they want to broker the data out to SalesForce.

Once the Web form is submitted, it hits maps to a circuit on the Vordel Gateway which first calls out to the EmailVerify API to verify that the email address in the form is valid.

So, here is the form which is submitted. I've entered info for a user called "Joe Demo" here in Boston. Note that I had to give him a valid email address (my own email address!) because the EmailVerify API really does validate the email address and so "joe.demo@example.com" would be blocked.


In the Real-Time Monitoring on the Vordel Gateway, we see the API calls out to the SalesForce login service (to get a SalesForce Session which the Gateway then caches), the EmailVerify API, and SalesForce's API itself, which we use to register the data from the form as a new lead in SalesForce.



And, sure enough, "Joe Demo" is now in SalesForce:


How does this work? If we look at the circuit in the Vordel Policy Studio, we see that the mashup of the EmailVerify API with the SalesForce API is done using simple "drag-and-join" configuration. No coding is required. As well as connecting to the two APIs, we are also enforcing an SLA over the connection to SalesForce, as you can see. Notice also how we are caching the SalesForce SessionID.


An interesting aspect of the SalesForce integration is the protection of the API keys used to access SalesForce. Notice how the Vordel Gateway encrypts all of the SalesForce credentials, as shown below. Vordel is a member of the Cloud Security Alliance and has provided guidance on the CSA blog about protection of API Keys. This is how we do it in the Vordel Gateway:



If you want to get your hands on this demo yourself, and experiment with brokering and mashing up SalesForce and other APIs, contact info@vordel.com

Vordel covers your *aaS at SOURCE Boston 2012

My colleague Jeremy Westerman is speaking at SOURCE Boston on "Covering your *aaS - Cloud Security Case Studies for SaaS, PaaS, and IaaS". His talk is on Wednesday April 18 at 10am, right after Dan Geer's keynote [the agenda is here]. Unfortunately I'll be out of the country and will miss it, but check out Jeremy's talk if you're in the Boston area and interested in all aspects of Cloud security.

OpenAM interop with the Axway API Gateway (Vordel)

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

Norway's ForgeRock provides support for OpenAM, the product formerly known as OpenSSO, and before that, Sun Access Manager.

Recently I setup interop with OpenAM using the Vordel Gateway, and here are some screenshots of this in action.

Here is I added the connection to OpenAM under the "External Connections" section in the Vordel Policy Studio:



In the Settings section for the Gateway, also in Policy Studio, I setup the connection as shown below. I used a local DNS setting for "sso.example.com" for the purposes of my setup:


I then used a HTTP Authentication filter to do authentication against OpenAM, and then followed it with a "Create Cookie" filter which inserts the SSO token as shown below:



Finally, here is the policy in action on the Vordel Gateway, when I test it using the free SOAPbox testing tool. You can see the SSO token has been injected into the response as a cookie (using the Create Cookie filter in Policy Studio):




Thursday, April 5, 2012

Vordel at the European Identity and Cloud Conference 2012

APIs and Identity Management are two closely related areas. On the one hand, Identity Management allows organizations to control who uses their APIs. On the other hand, APIs enable Identity Management infrastructure to be more easily deployed.

One of the biggest Identity Management conferences is the European Identity and Cloud conference taking place later this month in Munich. My colleague Axel Grosse is presenting a session at this conference, and taking part in a number of panel discussions. Be sure to check out Axel's workshops on Securing the Mobile API Ecosystem which takes place on Thursday 19 April at 2pm, and Bridging Mobile to On-premise at 4.30pm later that day. Also, at the conference Axel is participating in panel discussions on Securing the communication of Mobile Devices and Process Maturity Needs.

If you're in Munich for the conference, be sure to check out Axel's talks, and also visit Vordel at Booth P6.

Wednesday, April 4, 2012

Vordel API Gateway video demo

[Update: Vordel was acquired by Axway in 2012 and the Vordel Gateway is now known as the Axway API Gateway]

I've recorded a video demo of the Vordel API Gateway in action. With the API Gateway, much of the action happens behind the user interface (actually using APIs itself, as a matter of fact). The user experience is completely skinnable to customer requirements. The key is to use the capabilities of the API Gateway to make it as simple as possible for developers to sign up, and for clients to use the APIs using OAuth (with Facebook, Google, etc). Because, as Randy Heffner from Forrester pointed out in last week's webinar, if you make it hard for developers to sign up and use your API, they will go elsewhere,

video

Tuesday, April 3, 2012

Computer Technology Review - All Cloud Models Are Not The Same


When talking about "the cloud", it's important to differentiate between IaaS, PaaS, and SaaS. "Cloud" can mean a lot of things. This differentiation is the main theme of this article I've written for Computer Technology Review (CTR) about how all cloud models are not the same, and how security applies to each.


Monday, April 2, 2012

David Roe at CMSwire covers Vordel's Sharepoint Gateway

"Vordel shot across the radar with the release of its SharePoint Gateway solution that enables users to share data between SharePoint; mobile workforces and non-Microsoft applications."

Read more at:

Job posting: CA SiteMinder and Vordel expert for Global Investment Bank in London

This job was posted on March 28 looking for a CA SiteMinder specialist in London with Vordel Gateway skills:


This Middleware SSO Engineer role in London looks to be related also:

API Gateway support for HATEOAS: First do no harm

I often think it's ironic that while the mission of REST is to simplify Web development, REST itself is beset with seemingly complex jargon and architecture patterns. I say "seemingly complex" because, once you look into REST architecture in depth, it actually is simple. In some ways, it's almost too simple. It's easy to rack your brains about some REST pattern, but then realize: It's just how the Web works. I'm reminded of the line from Moliere about the bourgeois gentleman who spends years trying to understand how he could speak in "prose", then he exclaims "Good heavens! For more than forty years I have been speaking prose without knowing it". So it is with REST. HTTP verbs, URLs, and resources are just what we've been doing for years.

There are various levels of REST though, most famously categorized in the Richardson Maturity Model. At the top of this maturity model is HATEOAS. Actually I think "maturity model" is a bit of a misleading name, because ideally you don't want to start with a very brittle URL and then "mature" it to HATEOAS, since that puts undue requirements onto your client applications. It is better to start with HATEOAS principles from the start.

But what is HATEOAS (and how do you pronounce it?). Well, it stands for Hypertext As The Engine Of Application State. As with everything REST, the concepts come from Roy Fielding's paper. The core idea is that the HTTP server serves out links which guide the client as to what they can do with a particular resource. So, for example, if I do a GET on a product listed in a catalog, I receive back a series of links which are the actions I can perform on it. I may be able to get the price of the product via one of the links, order it via another link, get back a description of it via another link, or get back its weight via another link. My application may also may be provided an "up" link back to the main list of products. The powerful concept is that the links are all the actions my app can take on the resource. So, if I am not allowed to order the product, then I will not be given the "order" link. The client app can then take this into account ("I wasn't served up the "order" link for this particular product, therefore I will not provide the user with the ability to order it"). If you can order it, and do order it, then you may not be served up the "order" link for that product anymore, but (because you've ordered it) you may be served a link to view your order. This is the stateful aspect (it "knows" you've placed the order, and in fact that information is conveyed by the hypertext itself).

Another example is iteration through a set (for example, a list of products). As I am returned back each batch of results (e.g. the first 50, the next 50, etc), I get back a link to the previous batch of results (unless it's the first batch, then there is no "previous" link provided) and to the next batch (unless it's the last batch, then there is no "next" link). In this case also, all possible links are provided back to me. So it is also stateful (when I am on the second batch of results, it "knows" to give me link back to the first batch).

Providing all possible links, right inside the hypertext response, is a powerful concept. It's very different from the SOAP/WSDL world, where you must look at the WSDL in order to find out what actions (operations) are available to you. With HATEOAS, there is no "WSDL", instead the possible actions are in the response. The SOAP analogy would be where each SOAP response contained a WSDL that listed all of the subsequent operations the client could invoke. Another way HATEOAS is different is that, in the SOAP/WSDL world, if the WSDL changes, then SOAP/WSDL client apps must often be rebuilt. With HATEOAS, the service provider can add another capability, and it comes back as a new link in the hypertext responses, but this does not "break" anything. Similarly, removing a capability translates to removing a link, which should already be handled gracefully by the application.

With HATEOAS, the (hypertext) responses guide the client through their interaction with the resource, by providing links to the actions they can perform, so therefore the hypertext pages themselves become the engine of state. Hence the term, Hypertext As The Engine Of Application State.

[ Regarding
pronunciation of HATEOAS, I've heard it pronounced like a breakfast cereal or chip snack ("hate -o's") and also I've heard the edgier "hate yo' ass". ]

So, how does an API Gateway cater for HATEOAS? A key requirement is not to break it. As in medicine, "first do no harm". Consider what an API Gateway does: It provides external-facing APIs to the public, then translates them to back-end (usually on-premise) API calls.

Take for example the following JSON returned by a server to a client. The client has done a GET to get product information. The response includes a link to order the product, and it also an "up" link to go back to a higher-level view.

{
"id": "8000",
"links": {
"self": "http://myBackEndAPI:8000/v5/products/123456"
},
"ordering": [
{
"id": "8000-123456",
"links": {
"self": "http://myBackEndAPI:8000/v5/orders/8000-123456",
"up": "http://myBackEndAPI:8000/v5/8000"
},
"customer_id": "8000",
}
]
}

We see in the response above that the address of the back-end API server (myBackEndAPI:8000) is inside the JSON. When an API Gateway is used, clients go through the API Gateway, and should not go to the back-end API server directly [in fact, usually the API Gateway is cloud-based, and the API implementation is on-premises not directly accessible except through the API Gateway]. Therefore, the API Gateway must selectively replace the address of the back-end API server with the public-facing API server address, and it must do so throughout the responses, whether they are JSON, XML, or another format.

For our example above, the response may become:

{
"id": "8000",
"links": {
"self": "http://api.mycompany.com/v5/products/123456"
},
"ordering": [
{
"id": "8000-123456",
"links": {
"self": "http://api.mycompany.com/v5/orders/8000-123456",
"up": "http://api.mycompany.com/v5/8000"
},
"customer_id": "8000",
}
]
}

When requests come back from the client, it must also selectively change this address information, not only in the request URL but also in the payloads being POSTed or PUT to the REST API.

So how is this done? In the case of Vordel's API Gateway, such content substitution is provided as standard, and is implemented in a high-performance manner so that the URL replacement required to support HATEOAS will not impact on the user experience for your users. Really, what is involved here is analogous to how an application gateway always operates, with the extra stipulation that it must convert information within messages also. But, substituting information within messages is simple with Vordel's API Gateway, and already widely used such as in simple search/replace scenarios. All of this enables Vordel to support HATEOAS for our API Gateway customers.