Thursday, December 22, 2011

Testing HTTP Authentication to a Web API

It's natural to concentrate on the New New Thing, but in the case of authentication web APIs, based on HTTP, there are options. There is certainly HMAC authentication for APIs, as shown in this Vordel Gateway case study. But remember that HTTP authentication still exists, and can be used for authentication to an API. If you want to test this, you can pick up the free Vordel SOAPbox tool which, although it has "SOAP" in its name, can be used to test REST APIs also. Here is how you do this:

Firstly click up on the title bar for your API call:

You'll now see the "Request Settings" dialog. Notice that it's a GET request (not a POST in the case of SOAP). I then choose the lower "Security" tab and the upper "HTTP Authentication" tab, and configure my parameters there. Notice also that mutual SSL and Kerberos are options too.

Happy testing!

Tuesday, December 20, 2011

NFC - a "hand wavy" technology that may succeed

In the deluge of tech prediction lists which come out this time of year, one commonality stands out: NFC. NFC stands for Near Field Communication. Here you can see it at Number 3 on CNN's list for 2012. Like Microsoft Kinect or the Nintendo Wii, it is one of those technologies you can literally describe using "hand-waving". This is because the most highly cited usage for NFC is to enable you to wave your phone at a payment terminal and pay for goods.

Although mobile payments is the most commonly mentioned case for NFC, it has many other applications. For example, Transport for London plans to use NFC cards with its Oyster readers. And, back at Halloween, Mark Diodati from Gartner published a blog post (and Smiths reference in the title?) about the usage of NFC to literally open doors. The description of the experiment, where students used either a modified phone case or a MicroSD card with an attached antenna, reminded me of the early attempts to place digital certificates and private keys onto mobile phones via battery case appendages, circa 2000, in an ill-fated attempt to "PKI-enable" phones. That was ahead of its time, but here I think NFC is about to happen. 2012 may not be the "year of NFC" but it will be the year it continues its adoption, as gradually more and more people have an NFC-enabled phone in their hands.

As full disclosure, one of the large NFC players uses Vordel Gateways in its infrastructure. So I guess I have some other interest in NFC taking off. But, really it is one of those technologies which just makes too much sense to not take off in the coming years.

Thursday, December 15, 2011

Checking against a CRL from a Mutual SSL connection

A common scenario for an Application Gateway is to perform mutual SSL and then check the client certificate against a Certificate Revocation List (CRL).

Here is a simple circuit which check a Certificate Revocation List following SSL on the Vordel Gateway:

First things first

Firstly, it's important to setup an HTTPS listener on the Gateway which is requiring that a client sends a mutual SSL certificate to it. To do this, in Policy Studio, look under "Gateway", the "Listeners", and then your Gateway instance and then a particular Services group (by default there is one there called "Default Services"). You can right-click here, on your Services group, and choose "Add Interface" and then "HTTPS".

Here you choose your port for SSL (by default this is 443, but ensure that nothing is already running on that port or else when you try to deploy, the Gateway will detect this and tell you). Under the "Mutual Authentication" tab choose the option to "Require Client Certificates". In my example I have set the "Maximum Depth of Certificate Chain" to "3". Now ensure that you check the CA Certificates of all certs which will be trusted to be sent by clients. It's important to note that here you are checking the CA Certificates. If you have 1,000 clients who are sending certs all signed by the same CA, clearly it would be infeasible to check 1,000 boxes, one for each client. Instead, the trust is at the CA level.

[ Note: If you want to ensure that clients can only access your APIs or services over SSL, then simply delete the existing plain HTTP entry under the Services Group. Or, create a new "HTTP Services", only put an HTTPS listener in there, and then the only way to access the paths in that group is through SSL].

Next, right-click on your Services in Policy Studio again and this time choose "Add Relative Path". For my example, I am adding "/SSL" and it links to the policy I've made.

Step by Step

So, now let's look at the policy, step by step:

SSL filter. This filter is from the "Authentication" group in Policy Studio. The purpose of this filter is to force SSL authentication and to retrieve the certificate which is presented by the client. If you hover the mouse over this filter, you can see that one of the attributes it creates is a "certificate" attribute, which is the certificate presented by the client.

Check certificate against CRL filter. This is a "CRL (Dynamic)" filter. It is from the "Certificate" group in Policy Studio. I have configured the URL to "http://localhost:8080/GetCRL/MyCRLName.crl" . This means that the CRL is being served up by the Gateway (which is also listening on port 8080) using a Static Content Provider. The Static Content Provider is essentially a Web Server, which serves up the content of a directory. In this case, I map it to a folder on the same machine as the Gateway. I then place the CRL in there, and, under the services entry under "Listeners" in Policy Studio, I right-clicked and choose "Add Static Content Provider", and then pointed it at this directory. You can verify it works, once you deploy this, by simply pulling the CRL down through the browser (point your browser to: http://GatewayAddress:8080/GetCRL/MyCRLName.crl).Note that you must not have anything listening on the "/" path, since that takes precedence over the Static Content Provider here.

"Certificate is Valid" and "Certificate is not Valid" filters. These are simply "Set Message" filters, which return a message of "Certificate is Valid" or "Certificate is not valid", depending on the outcome of the CRL check filter above them in the decision tree. I choose the content-type of "text/html" since I am testing this with a browser.

"Return HTTP 200" filter. This is simply a "Reflect" filter, which returns the message I've set ("Certificate is valid" or "Certificate is not valid") with a HTTP response code of 200.

Testing this

In order to test this, I imported a client certificate into the "Personal" group of certificates in Internet Explorer. For some reason, the certificates configuration in Internet Explorer is under the "Content" tab (not the "Security" tab as you might expect) in Tools->Internet Options. This is where I clicked "Import" and imported a certificate to test. I then opened up https://GatewayAddress/SSL in the browser and presented my certificate for authentication. I then received the "Certificate is Valid" response from the Gateway, and in the Gateway's Real-Time Monitoring (port 8090) I could see the successful path through the CRL-checking policy.

Monday, December 12, 2011

Leveraging Cloud Computing for the Financial Services Sector - Bob's Guide

I've written an article on Leveraging Cloud Computing for the Financial Services Sector for Bob's Guide in London.

Some key points are brokering:
One option to achieve this is to use a broker architecture that ensures an organisation does not hard-wire its infrastructure into a single cloud provider. This approach enables organisations to easily choose between cloud service providers and manages the subtle differences between the various providers, in terms of pricing, how an organisation connects to them and how it manages the associated keys and so on.
And tokenization:
Many IT managers have been wary of cloud computing because of the prospect of private and sensitive data being sent up to third-party cloud services. However, with the development of technologies enabling the tokenization of data, there is now an opportunity to replace any private information with a random token that can be sent to the cloud service provider, and then swapped back with the real data when retrieved. In this way, the private data is never sent to the cloud provider. Usage of tokenization will certainly help the broader adoption of cloud computing within the financial services industry.
Check out the whole article here.

Friday, December 9, 2011

Identity propagation from the Vordel Gateway with Oracle IdM through to Oracle OSB

I've put together a diagram showing one of the scenarios where the Vordel Gateway operates with various Oracle Identity Management products. The scenario, which is very common, is Identity Propagation. If a client is authenticated at the Gateway, it's usually important to propagate their identity right through to the app server tier, because otherwise all requests may appear to simply come from the Gateway. It's also important for audit trail reasons (you need identity information available if you want to keep a trail of who has accessed which service).

One of the underlying technologies used for this is SAML, and you can seem more information about how we do it in this blog post I wrote after setting this Vordel-OSB interop up myself. You can follow these instructions to setup the identity propagation scenario.

In the diagram below, the Vordel Gateway is working with a number of Oracle IM products (OAM, OES, OVD, OWSM - see a naming pattern there? ;=) ) to provide end-to-end identity propagation from the edge of the network through to the app server.

For more information about Vordel Gateway interop with many Oracle products, check out

Wednesday, December 7, 2011

Using Vordel SOAPbox to send a SAMLResponse structure for SAML-based SSO

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

The SAMLResponse structure is often used for SAML-based single sign-on to Web apps. For example, it is used by SalesForce. In order to test an API or API Gateway which expects a SAMLResponse, SOAPbox can be used. In the example below, I have taken a SAMLResponse which was generated and URL-encoded by the Vordel Gateway. I have placed it into the "Request" field of SOAPbox:

When I send the SAMLResponse to the Web App, it must be sent with a content type of "application/x-www-form-urlencoded". Here, under the "Headers" sub-tab, is how I set this:

When, when I press the triangular green "Play" button, the SAMLResponse is sent. In this way, you can tee up example SAMLResponse structures for testing purposes. Happy testing!

Monday, December 5, 2011

Configuring a dynamic CRL lookup on the Vordel Gateway

Certificate Revocation Lists (CRLs) have long been used to in the context of PKI (Public Key Infrastructure). The Vordel Gateway makes it simple to validate a certificate against a CRL. Here are the steps for the case where a certificate is pulled down from a URL:

1) Place the certificate you want to validate into a "certificate" attribute. If you've validated a signature then you'll have this step done for you already, since the signature verification filter automatically populates a "certificate" attribute with the certificate used in the signature. Alternatively, you can use a "Find Certificate" filter to find the certificate from the local Gateway certificate store, or from an LDAP directory, etc.

2) Now, use a "CRL (Dynamic)" filter to pull down the CRL from a URL automatically. Note that any certificate used to sign the CRL must be present in the Gateway's Certificate store, since the Gateway will validate the certificate of the CRL's signature. The filter will return TRUE (green path) if the certificate is not on the CRL, and return FALSE (red path) if the certificate is on the CRL (i.e. it's revoked).

And that's all you have to do. All the hard work of validating the certificate against the CRL is done for you using the "CRL (Dynamic)" filter. It's another example of where using an Application Gateway is much easier than trying to do the same thing yourself with code.

Rutrell Yasin on "what to look for in a SOA App Gateway"

Rutrell Yasin at Government Computer News covers the new "Forrester WaveTM: SOA Application Gateways, Q4 2011" report in his article on "what to look for in a SOA App Gateway". I'm pleased to say that Vordel is positioned as a "Leader" in this Forrester report. What is a "Leader" in this context? Well, Leaders were recognized for their "wide-ranging support for message formats and protocols (including FTP) and strong content transformation features", plus "attack protection and trust enablement security features". Forrester recognized Vordel as a leader whose "… offering is strong overall …with a good global presence … and customer references [that] expressed strong satisfaction with the company and the product." The report also mentioned Vordel's important partnership with Oracle.

I worked opposite Forrester on this evaluation, and I was very impressed with how hands-on Randy Heffner and his team were. I know people can be cynical about analyst reports, but certainly in this case the products were examined in great detail, including hours devoted to show-and-tell product demo. A very valuable exercise for all involved: analysts, vendors, and customers.

Saturday, December 3, 2011

From XBRL to Westminster

I was looking up an XBRL expert in the UK recently, Steve Baker, and I discovered to my surprise that he is now Conservative Party MP for Wycombe! Of course, Steve is a smart guy and I always respected his views on XBRL, so it shouldn't be a surprise that he would be skilled in other areas. I look forward to XBRL markup in Hansard :-)

This is quite the update he has in his blog:

Suspended software work – now an MP

October 24th, 2010 by sjb

Now that I am MP for Wycombe, I have suspended trading as a consulting software engineer.

Thursday, December 1, 2011

How to call a Web Service or API "Off to the side" from the Vordel Gateway

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

A very common question asked by Vordel Gateway users is "How do I call out to an API or Web Service from within the Gateway, then use the response in a request to another destination?". I notice that people often gravitate to the "Web Service Filter" or "Call Internal Service" filter for this, but that's actually not how it's done.

The way to do this is to use the "Connect to URL" filter. In the example below, I am calling out to a REST API from within a circuit on the Vordel Gateway. You can see that because the initial request to the Gateway is a POST (it's a SOAP message coming in) and the call out to the REST API is a GET, I'm using a "Set HTTP Verb" to set the verb to "GET" before making the request to the REST API (a REST STS in this case, to request a SAML Assertion). I then am taking the response from that service, and using it in the construction of a request to the destination Web Service, which is an SP (Service Provider) that expects a SAML Assertion to be sent to it.

It's quite easy, in this way, to string together many calls to different APIs or Web Services.
Note that if you want to store the initial request, make the callout "off to the side" to another service, then restore the initial request (i.e. not overwrite it with the response from the service you called "off to the side") then that's where the "Store" and "Restore" filters are used.