Connecting SOA to the Cloud

Scheduling reports on API usage

2012-01-25T18:16:00.002Z

One really neat feature in the Vordel Application Gateway is the ability to schedule reports on API and Web Service usage. You can schedule reports to run on a regular basis, and have the results emailed to the user in PDF format, just like Google Analytics. These reports include summary values at the top (for example, the number of requests, SLA breaches, alerts triggered, and unique clients in a specified week) followed by a table of APIs and Services, and their aggregated usage data (for example, the number of requests on each API or Web Service).

It is quite simple to configure this with the Vordel Application Gateway. Just right-click the Listeners -> Vordel Reporter node in the Policy Studio tree, and follow the configuration steps which are listed here on the Vordel Extranet: https://extranet.vordel.com/documentation2/VG6/common/tutorials/reporter_scheduled_reports.html [ If you need a logon for the Vordel Extranet, contact Vordel at info@vordel.com ].

Gateways and Load Balancers

2012-01-17T14:34:00.001Z

A very common question is "How do Application Gateways work with Load Balancers"?

To answer this question, it is useful to divide up the load balancing requirement into "in front of" (ingress) and "behind" (egress) the Gateways.

In front of the Gateways (ingress), if there is already a load-balancer in place, then it's natural to deploy the Gateways in Active-Active configuration behind it. If the reporting or routing requires the source IP address, then load balancer can place this into the X-Forwarded header and the Gateway consumes this.

Policy Director is used to send the same configuration to multiple Gateways in an Active-Active cluster (and if there is a hot-standby, then to it also).

The distributed caching across the Gateways is used to keep state (eg message counts for throttling across Gateways in a cluster).

If there is no load-balancer in place, then it's simple to setup a cluster of Gateways with a VIP (Virtual IP address) shared across them. Policy Director is used to keep the configuration in sync.

Behind the Gateways (egress), you can use the Gateway's inbuilt load-balancing. This can be Round-Robin across backend servers, or weighted on response time (Gateways will then favor faster backend servers). So there is no need for a Load Balancer behind the Gateway. Load-balancing in the Gateway is configured within a "Remote Host" in Policy Studio.

Who manages Application Gateways?

2012-01-11T13:55:00.008Z

Because Application Gateways touch on a number of areas of functionality, including networking and security, a very common question is "Who manages an Application Gateway?".

To answer the question, take a step back and think about what an Application Gateway is. An Application Gateway takes tasks such as application integration and application security and it moves them into a piece of network infrastructure (which may be virtual or physical). By moving these tasks out of applications and onto the network, you make the tasks run faster, and easier to manage since they are now decoupled from the applications themselves.

So, breaking it down, there are two things going on here: (1) moving integration and security tasks onto network infrastructure, and (2) managing the Gateway as a piece of network infrastructure. It follows logically that there are two distinct roles involved here: (1) The person configuring services and policies on the Gateway, and (2) the person operationally managing the Gateway. Person (1) knows about APIs, apps, and policies. Person (2) does not need to know anything about APIs (much less know anything about REST or XML) but knows all about SNMP, Splunk, load-balancers, and NAT.

This is why Vordel provides two distinct training courses, aimed at these two different people. For person (1), who will be registering APIs and SOAP services on the Gateway and applying policies to them, we provide the Vordel Certified Systems Engineer (VCSE) training. This involves registering APIs (via their URLs), choosing policies to apply to them, and pushing the policies out to Gateways. It includes SOAP and REST. For person (2), we provide the Vordel Certified Network Administrator (VCNA) training. This explains how to monitor the "speeds and feed" of a Gateway, where alerts can be sent, how to monitor it via network admin tools such as HP Arcsight, how to deploy additional virtual appliances in a VMware ESX environment, etc.

The separation of duties carries over to the Web-based interfaces used to manage the Vordel Application Gateway. In the case of the person managing APIs and policies, they see dashboards such as the one shown above. Here I see the traffic being passed to three APIs: CDYNE's EmailVerify service, SalesForce itself, and SalesForce's login service, for a two minute period on January 9th 2012.

In the screenshot above, we see what the Network Administrator sees. Rather than seeing information about SalesForce APIs, they instead see the network administration view of the Application Gateway. We see, for example, here the RAID Array Status for disks in the Application Gateway. Also, as you can see, system logs, networking, and server status can be monitored in this way. All of the same information can be sent to a product like HP Arcsight so that the network administrator does not even need to look at Vordel tooling.

In summary, there are two distinct types of people who manage Application Gateways on an ongoing basis, and this maps to Vordel's two distinct training courses, and to the different Web interfaces we provide for these people. All of this is geared towards moving application integration application security out of applications and onto the network (virtual or physical).

Kin Lane's API Management Service Provider Roundup for 2011 covers Vordel

2012-01-04T02:36:00.003Z

Vordel is featured in Kin Lane's First Dimension of API Management Service Providers. It's a really good round-up of the current state of play, as we start 2012.

Kin mentions that:

One thing to know about these API management service providers is, well...they are API management service providers. To my knowledge they don’t actually deploy your API for you, they help you build a strategy, and manage the API. But you still need to rely on other tools and in-house resources to deliver your API.

This is where I'd disagree slightly. In the case of an API Gateway, it can also be used as a service delivery platform to deliver an API in front of existing enterprise system systems. This is because API Gateways include many adapters to, for example, various message queues, TIBCO EMS/Rendezvous, databases, and FTP/SFTP. These are used to deliver a REST API interface in front of an enterprise system which does not natively support REST, not to mention JSON, OAuth, or OpenID. This can be as simple as delivering a REST API interface in front of an existing SOAP service within the enterprise, to mapping from REST into messages placed on the message queue, through to mapping from "lightweight" identity mechanisms suitable for APIs (such as OpenID or OAuth) through to enterprise identity management (e.g. mapping from Google OpenID to Oracle OAM). So, an API Gateway usually does not only manage the API, it actually delivers the API too.

Mapping from Google login, with OpenID, to Oracle Access Manager login, with obsso cookie

2012-01-04T02:13:00.005Z

For a demo recently, I configured the Vordel Gateway to map from a Google account logon to an Oracle Access Manager obsoo cookie. This was to enable users to use their Google account to log into a local enterprise service, using the Vordel Gateway to do the mapping to the Oracle Access Manager login (since Oracle Access Manager is what is protecting the enterprise service).

Here is the policy in action. You can see that the Vordel Gateway creates a hyperlink to Google, to ask the user to select their account. If you look at the status bar in the screenshot below, you can see the OpenID string generated by the Vordel Gateway:

When I click the link, I am asked which Google account I want to use to log into the service. Google shows me the two accounts which I am currently logged into:

Once I choose the Google Account, I see that the Vordel Gateway has generated an Oracle Access Manager obsso cookie, which is visible in Firefox:

If you're interested in getting a copy of the policies I used for this, contact Vordel at info@vordel.com . For more information, including videos, about Vordel Gateway interop with various Oracle products, check out: http://www.vordel.com/oracle/

Returning JSON fault information to JQuery-based API clients

2012-01-03T02:42:00.006Z

Since many APIs are called by JavaScript libraries like JQuery, it's convenient to return fault information as JSON so that it can be easily read by the client. The object is then parsed to retrieve the reason for the fault. Some APIs make this easy, such as the Rackspace Cloud Identity API which allow faults to be returned as JSON or XML. But in many cases, you have to laboriously configure this JSON conversiona yourself [For example, in the case of WCF, Iain Mitchell has a good blog post about how it can be made to return JSON formatted faults for consumption by JQuery.]

A Gateway serves an important purpose here, by providing fine-grained information on why clients are blocked. A Gateway can XML to clients which expect XML responses, and JSON to REST API clients which expect JSON. Let's see how you can use the Vordel Gateway to take a policy which returns an XML fault (in this case a SOAP Fault) and converts it automatically to JSON...

To start this, I fired up Vordel Policy Studio and connected to my Dev API Gateway. I then dragged in a Policy Shortcut to a policy called "JSON Fault". Next I right-clicked on it and choose "Set as Fault Handler", as shown below:

This means that if any of the filters in the chain return false, my policy gets called. Next let's look at this policy. You can see below that it takes a regular SOAP Fault and converts it automatically to JSON:

When we look at it in action, in the API Gateway's Real-Time Monitoring, we see the familiar "Path through the policies" on the left, and on the right you can see the JSON which is returned to the JQuery client:

The API Gateway's Real-Time Monitoring shows what is happening now for your APIs and services. But in order to look at what has happened in the past, we open the API Gateway's audit trail. Here you can see the opening page, and I click on the "Audit Trail" button:

On the Audit Trail, I run a report for the API requests blocked in the last hour by my API Gateway. Here I see a bunch, and I click on one to see more detail.

When I click on the API request which was blocked, I see the exact reason why it was blocked in the "Path through the Policy". I can see below that it was the authentication which failed, the same reason which was passed back to the JQuery client.

So in summary, it's quite straightforward to return JSON fault information to clients, and view fault information in the Audit Trail, using the Vordel Gateway. To get more info, or your own copy of the Vordel Gateway, contact us on info@vordel.com

How to change the default alert email subject line

2012-01-02T21:11:00.003Z

First How-To of 2012 and it's via Niall Commiskey, who posted a useful tip which applies also to the Vordel Gateway: How to change the default alert email subject line.

Testing HTTP Authentication to a Web API

2011-12-22T15:40:00.003Z

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!

NFC - a "hand wavy" technology that may succeed

2011-12-20T17:32:00.005Z

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.

Checking against a CRL from a Mutual SSL connection

2011-12-15T14:50:00.005Z

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.

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

2011-12-12T17:39:00.002Z

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.

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

2011-12-09T16:23:00.004Z

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 http://www.vordel.com/oracle

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

2011-12-07T04:03:00.005Z

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!

Configuring a dynamic CRL lookup on the Vordel Gateway

2011-12-05T06:18:00.003Z

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"

2011-12-05T02:34:00.004Z

Rutrell Yasin at Government Computer News covers the new "Forrester Wave^TM: 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.

From XBRL to Westminster

2011-12-03T20:10:00.005Z

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.

http://www.ambrielconsulting.com/?p=133

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

2011-12-01T18:53:00.007Z

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.

Video: Enabling OAuth to a Google JSON API using the Vordel API Gateway

2011-11-28T06:35:00.005Z

OAuth is a very popular way to manage access to APIs. Amongst other things, it enables users to log into an application (which could be an application on a phone or tablet) and then that application calls lightweight APIs on their behalf. From a user's point of view, they accessed the application, and it all "just worked". They didn't have to enter any more passwords. From an implementation perspective, it's more complex of course. But an API Gateway makes it simple to call lightweight APIs using OAuth.

When I say "Lightweight APIs" in the paragraph above, I mean REST Web Services which generally use JSON. And what is JSON? JSON is a lightweight alternative to XML, which is increasingly used to bypass heavyweight XML parsing (and, in some cases, to bypass the security controls of the XMLHttpRequest object often used in AJAX).

JSON and REST can be seen as more efficient optimizations of what went before. OAuth is far from being "just another authentication mechanism". To understand OAuth involves understanding how it is used. For APIs, it generally involves an application (e.g. an Android app) accessing the API on the user's behalf. Phil Hunt has an excellent explanation of this aspect of OAuth here:

OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner's (e.g. the user) behalf using only HTTP to access REST based services in a lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified "scope".
http://www.independentid.com/2011/04/oauth-does-it-authorize-yes-but-much.html

[ It's also worth following the link above to Phil Hunt's piece if you're ever wondered why the HTTP header "Authorization" is not called "Authentication"]

So, all in all, there are a lot of new technologies at play here: OAuth, JSON, APIs, and even REST. And there is also a new concept, the API Gateway. An API Gateway applies the security mechanisms such as OAuth, which is required to authenticate to an API. But, beyond this, it also provides:
- Monitoring of the API usage
- Alerting if the API is not responding correctly
- An audit trail of API access
- Validation of API content
- Redaction and tokenization of content being sent in API calls
- Mapping to identity stores

Putting it all together, here is a demo of how a user can authorize the Vordel API Gateway to access a JSON API with OAuth on their behalf.

In the video below, I'm using an Android tablet to authorize the Vordel API Gateway to access an API on my behalf. In the Android environment, I am already logged in with Google, and the API Gateway leverages this to ask me do I want to access the API using my Google logon. In this case the API is a Google URL-shortening API. When I authorize it, then from that point on the Vordel API Gateway is enabled to access this API on my behalf. At the API Gateway level, you can see in the video that the API usage and access is managed. The API Gateway administrator can add controls such as JSON validation, detection of private data leakage, and tokenization (replacement of private data with an opaque token). At no point does the user have to worry about creating OAuth headers - this is all taken care of at the API Gateway.

This is the first in a series of videos on the API Gateway topic - watch this space for more!

"A guy walks into a bar..."

2011-11-22T18:37:00.004Z

I saw a good "A guy walks into a bar" joke retweeted via Roman Stanek's Twitter feed:

"An SEO guy walks into a bar, bars, pub, public house, Irish pub, drinks, beer, wine, liquor, grey goose, cristal"

I guess that is an old joke (though it was new to me: thanks Roman) but here's a new one: What would application security guy call an Irish bar? Not "O'Reilly's" or "O'Malley's" but "O' or 1=1--"

[ Explanation for non appsec folks: "O' or 1=1--" is an example of a SQL Injection attack which could be used against an API ]

How to check for a HTTP 404 response code from a service

2011-11-10T05:16:00.004Z

Here's a quick guide to checking for a HTTP 404 response code from a service, using the Vordel Gateway.

The first thing to note is that a "Connection" or a "Connect to URL" filter will return true if the back-end service returns a 404 code, because of the fact that the back-end service has successfully returned a response. You can then handle this 404 as you require. Often, it's a good idea to not return the full gory details of the 404 Not Found response to the client, and instead mask this information with a more friendly message. Or, you may wish to connect to a different URL instead. All of this involves branching on the value of the HTTP response code.

The simplest way to do this is to grab the latest version of the Vordel Gateway and check out the "Switch on Attribute Value" filter. This filter is great way to call a different policy shortcut based on the content of an attribute (in this case http.response.status).

Another way to do this is with a script. Below, I am using a script to check if the value of the http.response.status attribute is "404". If it is, I am branching to a "Set Message" filter which sets a nice friendly message to the client, telling them that the service is not available. Following that, I am using a "Reflect" filter to ensure that a 200 OK response code is returned to the client (not the 404 which came from the service).

Here is what the browser user sees. All of the information from the back-end service is replaced by the "Service not available" message.

This is pretty simple to handle at the Gateway, and it's interesting that, with relatively simple configuration like this, you can deploy the Gateway as Web traffic routing infrastructure.

How do I read an attribute from an LDAP directory, and place it into a SAML Assertion?

2011-11-09T16:28:00.010Z

Looking up user information from an LDAP directory is a common usage of the Vordel Gateway. Sometimes it's used for Message Enrichment in front of an applications server. This saves the applications server developer the hassle of looking up the attributes from the directory, since the attributes are handed to them on a plate, in the message, by the Gateway. So here is a quick tutorial on how to do this:

In the circuit you can see below, I am doing four things:

1) Authenticating the client against an LDAP directory (in this case Microsoft Active Directory) using WS-Security UsernameTokens.

2) Looking up attributes for the user (in this case, their telephone number)

3) "Injecting" a SAML 2.0 assertion into the message, including the SAML Attribute Statement

4) Passing the message back, with the SAML assertion now in it (so that we can see it). Here I could have used a "Connect to URL" filter to send the message to a URL, the "Messaging" filter to put it onto a queue, etc.

Let's look at each of these filters. Firstly, the filter which does WS-Security authentication against LDAP. This is shown below:

See that "Sample Active Directory Repository" under the "Repository Name" field above? That is a pointer to the connection I have configured to an LDAP directory. Actually, with the Vordel Gateway, you get a pre-configured sample LDAP connection which you can adapt to your own directory. This is what I did. The configuration for the LDAP connection can be found under "External Connections", as shown below:

You can see above that there are two things to configure: (a) The Authentication Repository Profile, and (b) The LDAP Connection itself. The LDAP Connection is how the Gateway binds to the LDAP server. The Authentication Repository Profile is how it finds the users which are being authenticated. So it is "bind then find". The Authentication Repository Profile (the "find") makes use of the LDAP connection (the "bind"). Note that if you only configure the LDAP connection, you won't see your LDAP authentication connection come up in the drop-down box on your authentication filters.

If I click on "Add/Edit", I can edit (and test) my LDAP connection. In the screenshot below, you can see that the test was successful, meaning I could connect from Policy Studio to the LDAP directory:

OK - so now let's look at the next filter in our circuit. This is a "Retrieve Attributes from Directory Server" filter, which you can find in the "Attributes" group in Policy Studio. I have configured it to retrieve the "telephoneNumber" filter from Active Directory:

If I look into Active Directory, I can see the phone number is in place for a sample user ("Joe Developer"). This is the phone number I am looking up:

Next, I am using an "Insert SAML Authentication Assertion" filter, and I have checked the box to place the SAML Attributes into it, as shown below:

So.... Now when I send a request to the Gateway on a path which is mapped to that policy (e.g. /MyAPI), I see that in the response I now have the SAML Assertion containing the user's phone number. Note that the WS-Security UsernameToken has been removed after use by the Vordel Gateway (you might have noticed the checkbox for this in the WS-Security configuration screenshot above).

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="Id-0001320855457809-800be35d4ebaa7a1120b3266-2"
IssueInstant="2011-11-09T16:17:37Z" Version="2.0">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
Example
</saml:Issuer>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
CN=Joe Developer,CN=Users,DC=Vordel,DC=com
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches" />
</saml:Subject>
<saml:Conditions NotBefore="2011-11-09T16:17:36Z"
NotOnOrAfter="2011-11-09T16:22:36Z" />
<saml:AuthnStatement AuthnInstant="2011-11-09T16:17:37Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="telephoneNumber"
NameFormat="urn:vordel:attribute:1.0">
<saml:AttributeValue>123456</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</wsse:Security>
</soap:Header>
<soap:Body>
<Add xmlns="http://startvbdotnet.com/web/">
<a>1</a>
<b>2</b>
</Add>
</soap:Body>
</soap:Envelope>

So that's it! That's all you need to do to authenticate a user against an LDAP directory, look up attributes, and insert attributes into an Attribute Statement in a SAML Assertion. You can find out more about the Vordel Gateway here, or email us at info@vordel.com to get a copy.

Protecting API Keys for Cloud Services

2011-11-02T05:37:00.004Z

My colleague Hugh Carroll has a good piece in Business Review Canada today about protecting API keys. Be sure to check it out. API keys are just as important to protect as other keys (e.g. SSL keys) but have not got nearly the same amount of awareness from security folks. How long before there is a major publicized API key breach?

How to configure load-balancing across services on the same host

2011-11-01T13:14:00.003Z

There is a neat feature in the Vordel Gateway v6.2 which allows you to load-balance messages across endpoints that are on the same host. In the configuration of a Vordel Gateway, we have had the concept of a "Remote Host" for a long time. A Remote Host allows you to assign an address to map to one or more addresses. This allows you to perform load-balancing across back-end machines which the Vordel Gateway routes to.

You can see in the configuration below that I have setup a Remote Host using Policy Studio, and I have setup three addresses which differ only on the port they use. I am calling the Remote Host "LoadBalancedRequests". This is not a name of a real machine, but that doesn't matter (think of a hosts file). Now, when I route messages to this LoadBalancedRequests destination, the Gateway load-balances the requests across three addresses, which differ only based on port. You can see also that I have set the load-balancing algorithm to be "weighted by response time".

By the way, you might be thinking "why would someone have three different endpoints on the same machine to load-balance over?". One good reason is if they are running three different app server instances, to take efficient advantage of the available CPU and memory. This scenario is actually quite common. So now you know how to accomodate it on the Vordel Gateway :-)

APIEvangelist.com covers Vordel

2011-10-26T19:15:00.003+01:00

Kin Lane, over at APIEvangelist.com covers Vordel as an example of an API Service Provider. He mentions that:

Vordel has an impressive client list including the FBI, Coast Guard and Dunn & Bradstreet, and delivers some progressive integrations, like a deployment of their API gateway for Blackhawk Network, which extends REST services to their business partners like iTunes and Facebook.

Kin mentions the Blackhawk Network API: For more info on this API deployment, check out the video of the API gateway deployment here (skip on to 14 minutes and 30 seconds in, to get to the core info about the API).

IdP (Identity Provider) to SP (Service Provider) SAML with the Vordel Gateway

2011-10-21T03:33:00.010+01:00

Signed SAML tokens are often used to propagate identity information in an API request. Although we're increasingly people using OAuth with the Vordel Gateway, SAML remains the established technology and is not going away anytime soon. Here is an overview of how you can create a signed SAML Assertion at the IdP (Identity Provider) then send this in an API request to a SP (Service Provider). As an extra architectural detail, I am issuing the SAML Assertion using a REST STS interface.

You'll notice below that I'm using the snazzy new Vordel 6.2 release, because of the new re-arranged search interface on the right, and the new "libraries" (blacklists, whitelists, etc) and "resources" (scripts, schemas, stylesheets, etc) groups on the left.

Here is the IdP policy. It's very simple. I am firstly authenticating the browser client, then calling out to a REST STS to request a signed SAML Assertion for the user. I'm the validating the signature on the SAML assertion.

That request to the REST STS? If I hit it directly with a browser, it looks like this:

Notice the response is signed and the digital signature is inside the SAML assertion. This means that the XPath used to validate the signature must not take the signature itself into account. The XPath for this is: (//saml:Assertion)/descendant-or-self::node()[not(ancestor-or-self::dsig:Signature)] . This is one of the example XPaths provided with the Vordel Gateway.

Now, I am placing the signed SAML Assertion into a form variable called SAMLResponse, as shown below. This is what I am sending to the Service Provider (SP):

<form method="post" action="http://sp.example.org:8080/SAML2/POST" ...>
<input type="hidden" name="SAMLResponse" value="PHNhbWw6QXNzZXJ0aW9uIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDph
(truncated)
Pg==" />
<input type="submit" value="Connect to Service Provider"/>
</form>

At the Service Provider, I Base64-decode the SAML Assertion in the Vordel Gateway, check its signature and the trust of its issuer, and then return the response from my service. I can see all this happening in the Traffic Monitor of the Vordel Gateway. I see the IdP service, the REST STS, and the Service Provider.

I double-click on any of the services, I see the tracking of what happened step-by-step inside the policy. You'll notice that the steps here map to the steps in the first screenshot above. The Traffic Monitor shows the time for each step also, as it runs on my laptop.

So that shows how you can setup an IdP, SP, and REST STS all on the Vordel Gateway. Now, normally you would not be running all these components on the same machine. But it's certainly a useful exercise to learn about how it all works.-->

Tablet-tastic new site

2011-10-18T04:26:00.003+01:00

If I can prise my Android tablet out of my kids hands for a moment, I can show the new tablet-optimized Vordel site. Neat new layout, and everything fits nicely on the tablet's screen.

And here's a tip for Vordel Gateway customers who use tablet computers. If you log into the Gateway's web interface with a tablet, all of the functionality is available to you:

For example, here is the Real-Time Monitoring:

Definitely an excuse to buy a tablet computer, if you don't have one already...

Video: Three Cloud Computing Case Studies

2011-10-10T18:43:00.011+01:00

When an organization says they are "using the cloud", it can mean a number of very different things. Using an IaaS service such as Amazon EC2 or Terremark is different from using Google Apps for outsourced email, which is different again from exposing an API into Facebook.

So here is a video of three Cloud Computing case studies from Vordel 's customers. They cover one each of SaaS, IaaS, and PaaS. In first two examples, customers are connecting up to the Cloud; firstly to Google Apps (for single-sign-on to Google Apps email) and secondly to Terremark to manage virtual servers. In the third example, the connection is from the Cloud (a Facebook app) to a company's APIs. Here's the video, and see if you can spot the Animal House references :-)

I made the presentation using Prezi, so you can click through the presentation (minus the audio) up on Prezi.com.

Today at Oracle Open World - Cloud SaaS, PaaS, and IaaS Case Studies

2011-10-04T14:52:00.003+01:00

Today I'm presenting three Cloud case studies at 5pm in Room 3022 in Moscone West, here at Oracle Open World. The case studies are one each of:

- SaaS (Software as a Service) for single sign-on to Google Apps
- PaaS (Platform as a Service) exposing business services as an API
- IaaS (Infrastructure as a Service) applying governance to the Cloud-based virtual machines

I had originally called my presentation "How to cover your *aaS" but that title didn't make it past the Oracle Open World selection judges :-)

Hope to see you there!

Automated API testing

2011-09-29T04:53:00.003+01:00

If you download the free SOAPbox testing tool, you may not realize that (a) you can use it to test REST APIs, and (b) this testing can be automated.

SOAPbox comes with a command-line tool called sr (Service Request) which will automate requests to an API or Web Service. Here is how you can use it to call the healthcheck API on the Vordel Gateway, when the Gateway is running on the same machine:

sr -v GET -h localhost -u/healthcheck -s 8080 -p10 -d10

The "-p 10" means to run ten parallel threads. "-d 10" means to run for ten seconds.

Definitely a very useful tool to simulate and test API access.

Issuing a SAML Assertion with a simple STS on the Vordel Gateway

2011-09-27T05:30:00.005+01:00

Many different token formats are used in the world of SOA and Cloud. These include OAuth, UsernameTokens, X.509 Certificates, Kerberos tickets, and custom tokens such as the SiteMinder smsession. All these token types can cause confusion, and also introduce complexity if applications are expected to support them all.

To deal with this issue, it's a common practice to convert these tokens into a common token type. And, often, this is SAML. How it works is that, following validation, a SAML assertion issued which asserts that the token was validated. This means that the token itself no longer needs to be sent with the message. It also means that the recipient system only needs to understand SAML.

The piece of infrastructure which converts tokens is called a Security Token Service. Gunnar Peterson, in his Security Architecture for the Cloud, includes an STS as well as a Gateway as core components. In the case of the Vordel Gateway, a logical STS can be implemented with the Gateway. Let's look at how this is done...

We'll focus on a common scenario in the field: How a SAML Assertion is in response to a Username Token. The policy below, configured in the Vordel Gateway, takes in a UsernameToken, validates it, and issues a SAML Assertion in response.

Let's look at the chain of filters which are used to achieve this. Starting from the top in the screenshot above, we see:

Register Security Token Service for Monitoring. This is a "Set Service Name" filter, from the "Monitoring" group in Policy Studio, which I've configured to set the service name as "Security Token Service". Once this name is set, the service is visible in the "services" table of the Gateway's Real-Time Monitoring, as well as in any product which is monitoring the Gateway (e.g. Oracle Enterprise Manager).

Validate WS-Security UsernameToken. This is a "WS-Security UsernameToken" filter, from the "Authentication" group of Policy Studio. I've configured this to authenticate a user against the Local User Store in the Gateway, for simplicity.

Process STS Request. This is an "STS Web Service" filter, from the "Security Services" group in Policy Studio. This filter processes the incoming RST (Request Security Token) message, and constructs the "scaffolding" of the RSTR (Request Security Token Response) for us to place the SAML assertion into.

Insert SAML Authentication Assertion. This is an "Insert SAML Authentication Assertion" filter, from the "Authentication" group in Policy Studio. It inserts a SAML Assertion, and the NameIdentifier it places into the SAML assertion is taken from the username in the WS-Security UsernameToken (specifically, it comes from the authentication.subject.id attribute). Note that if you wanted to place a different name in the SAML Assertion, you could, for example, read the value from the message using a "Retrieve from Message" filter and then configure that filter to write the value into the authentication.subject.id attribute.

XML Signature Generation. This is an "XML Signature Generation", taken from the "Integrity" group in Policy Studio. I've configured it, under the "What to Sign" tab, to sign the SAML Assertion using the pre-built XPath for this purpose. Under "Where to place signature", I've chosen to place it into the WS-Security header for "Current actor/role only".

Return STS response. This is simply a "Reflect" filter, from the "Utility" group in Policy Studio. I am using this to return a 200 response code to the client.

So let's see this STS policy in action....

Here is an example message, which you can see is an RST (Request Security Token):

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-00000132a9381221-0000000001a99295-4"><wsse:Username>Joe User</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">vordel</wsse:Password><wsu:Created>2011-09-27T04:50:16Z</wsu:Created></wsse:UsernameToken>
</wsse:Security>
</soap:Header>

<soap:Body><wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"><wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType><wst:TokenType>SAML</wst:TokenType></wst:RequestSecurityToken></soap:Body>
</soap:Envelope>

I've wired a path in the Gateway so that requests to the path /STS-Example hit this policy:

So, next I use the free SOAPbox testing tool to send a request to this policy. As you can see below, I have loaded in my request on the left-hand side. I actually created the UsernameToken using the "Insert WS-Security UsernameToken" option under the "Security" menu. [Note that if you're inserting a UsernameToken to replace an existing one in the message, you must delete the existing one first]. I configured the UsernameToken as shown:

Then I pressed the little green "play" button on the toolbar to send my request.

You can see on the right that the response back to me is a signed SAML Assertion. That's all that's involved in creating a simple STS with the Vordel Gateway.

Authentication using custom tokens with the Vordel Gateway

2011-09-26T02:58:00.003+01:00

Although standards like WS-Security exist, it's a fact of life that many organizations use custom authentication tokens to authenticate clients. This happens for a variety of reasons, such as the fact that WS-Security presupposes the usage of SOAP, and that just isn't an option for many people in the world of lightweight REST-based APIs.

Supporting custom authentication tokens is simple with the Vordel Gateway. It consists of two steps in Policy Studio:

1) Read in the username and password into two variables (called "attributes" in the Vordel Gateway).

If you want to read in a username from a HTTP header, for example, then drag in a "Retrieve from HTTP Header" filter, and type in the header name (e.g. "Username"), and then the attribute ID you want the value to be read into (e.g. "authentication.subject.id"). If you want the value to come from the Query-String (i.e. from the name-value pairs after the "?" in the URL), the check the box called "Use Query String Parameters".

If you want to read in a username from the message itself, use a "Retrieve from Message" filter, and then configure it with the XPath used to find the value. Tip: Save a copy of a message, then use the XPath Wizard (hit the little "magic wand" icon) to open it and tell the Gateway where your custom token is.

Then a similar procedure to read in the password from the message header (the "Retrieve from HTTP Header" filter) or message body (the "Retrieve from Message" filter). Usually I read this into the attribute "authentication.subject.password".

2) Drag in an "Attribute Authentication" filter (you can find this in the "Authentication" group) and chain it after the filters you setup before. In the example below, you can see that I've read the username and password into the attributes "authentication.subject.id" and "authentication.subject.password" respectively. I now ask the Gateway to validate these credentials.

Catch the Vordel and Forrester Webinar next week: The Expanding role of the Gateway in a Modern IT Architecture

2011-09-23T23:36:00.003+01:00

Randy Heffner, Forrester analyst, and Vordel are presenting a webinar next Thursday at 11am Eastern on "The Expanding role of the Gateway in a Modern IT Architecture". It's a good chance to see how APIs and the Cloud are changing the game, and how Gateways apply now more than ever.

Attendees will learn how to:

Deploy Enterprise Applications Beyond The Network Perimeter
Consume Cloud Services Without Losing Control or Compromising Security
Secure All Application Connections Using Enterprise Security Infrastructure

Here is the free registration page.

Free Vordel Workshop next month - Hotel Nikko, San Francisco - week of Oracle Open World

2011-09-22T09:48:00.005+01:00

If you're in San Francisco for Oracle Open World next month, you can catch the wave, get your feet wet, and partake of other surfing metaphors at the free Vordel Workshop. This workshop will cover many Vordel tricks+tips, with a particular focus on Oracle interop. Here's the link to register, and here's the run-down:

Hands-on exercises and demonstration of using Vordel Application Gateway to:

Convert SOAP services to REST to enable mobile and Web 2.0 applications
Connect Cloud Applications to enterprise identity management for single sign-on
Leverage Oracle Access Manager to control access to Cloud based services
Enforce fine-grained authorization policies from Oracle Entitlements Server
Protect Oracle Service Bus from message level threats
Speed up your Oracle SOA applications by offloading XML processing and security tasks
Throttle service traffic and manage quota in real-time
Protect and audit Siebel's SOAP and REST service interfaces

Oh, and you get free stuff:

A free developer license to Vordel Application Gateway
Entry into a prize draw for a Pico Projector
A 16Gb USB 2.0 Hard drive
A limited edition Vordel Immerse T-shirt.

Content-based routing, with conversion for SOAP to REST, in the Vordel Gateway

2011-09-21T09:46:00.009+01:00

The Vordel Gateway has some really neat features which make it very easy to do content-based routing based on parameters in a SOAP message, and to use these parameters to construct a REST request. Here is an example of how this is setup. First, I register the WSDL service (a Parlay-X AmountCharging Service) in the Web Service Repository in the Vordel Policy Studio, as shown below:

Next, in the policy which is called in the Gateway for this service, I drag in a "Retrieve attributes" filter. I the used the XPath wizard to open an example of the Parlay-X message, and I choose the "EndUserIdentifier" value by navigating to it. This is shown below:

What happens now is that the value from the endUserIdentifier XML element is read into an attibute called "EndUserIdentifier". I then follow this with a "Switch on Attribute Value" filter, to switch based on the content of this attribute. You can see in the circuit view below that I am switching on the attribute value after I read in the attribute value:

Here is a view of the "Switch on Attribute Value" filter. I am looking at the value of the "EndUserIdentifier" value, and checking does it start with certain values. In this case, I am looking at the zip code value from a phone number in this element.

Finally, I am placing the EndUserIdentifier into a REST request to be sent to a REST API (in this case, the GSMA API):

The API parameters are created in a "Create REST Request" filter, as shown below. This is a very convenient way to construct a REST API request in the Vordel Gateway. As you can see, the EndUserIdentifier is being populated dynamically:

I then use Vordel SOAPbox (free download) to test this, by sending messages to the SOAP service:

In the Real-Time Monitoring of the Vordel Gateway, you can see the Gateway is now dynamically reading the value of the EndUserIdentifier element:

Contact info@vordel.com to get a copy of the Vordel Gateway to test this out for yourself...

How to authenticate then issue a SAML assertion in the Vordel Gateway

2011-09-16T06:18:00.003+01:00

Issuing a SAML assertion into a message with the Vordel Gateway is quite straightforward. If you follow an authentication filter with an "Insert SAML Authentication Assertion" filter, then a SAML assertion will be placed into the message after you've authenticated the client. Then, to call the target Web Service, you can use a "Connect to URL" filter, which results in the Gateway calling the target Web Service, with the client message which now includes the SAML assertion.

What about putting SAML attributes in that assertion? If you have authenticated the client against SiteMinder or Oracle Access Manager, for example, then you can check the "Insert SAML Attribute Statement" checkbox on the "advanced" tab of the SAML filter, and it results in the Gateway inserting in the SiteMinder smsession, or the Oracle obsso token, into an attribute statement in the SAML assertion.

Below you can see an example of a message sent into the Vordel Gateway, and following that you see the message after the SAML assertion has been inserted:

<soapenv:envelope soapenv="http://schemas.xmlsoap.org/soap/envelope/" tem="http://tempuri.org/">
<soapenv:header>
<soapenv:body>
<tem:getdata>
<tem:value>123</tem:value>
</tem:getdata>
</soapenv:body>
</soapenv:header></soapenv:envelope>

<soapenv:envelope soapenv="http://schemas.xmlsoap.org/soap/envelope/" tem="http://tempuri.org/">
<soapenv:header>
<wsse:security wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:assertion saml="urn:oasis:names:tc:SAML:2.0:assertion" id="Id-0001316150618498-71f75ed54e72dd5a12116c6c-2" issueinstant="2011-09-16T05:23:38Z" version="2.0">
<saml:issuer format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
MyCompany
</saml:issuer>
<saml:subject>
<saml:nameid format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
demo
</saml:nameid>
<saml:subjectconfirmation method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">
</saml:subjectconfirmation></saml:subject>
<saml:conditions notbefore="2011-09-16T05:23:37Z" notonorafter="2011-09-16T05:28:37Z">
<saml:authnstatement authninstant="2011-09-16T05:23:38Z">
<saml:authncontext>
<saml:authncontextclassref>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:authncontextclassref>
</saml:authncontext>
</saml:authnstatement>
</saml:conditions></saml:assertion>
</wsse:security>
</soapenv:header>
<soapenv:body>
<tem:getdata>
<tem:value>123</tem:value>
</tem:getdata>
</soapenv:body>
</soapenv:envelope>

How does this relate to an STS (Security Token Service)? The answer is that you can certainly see the issuance of that SAML assertion in the Vordel Gateway as an example of a security token being issued. Do you need to call out to an STS to do this? No. In this case the Gateway itself is issuing the SAML assertion, without any needs for callouts to anywhere.

You know you're a geek when...

2011-09-12T21:51:00.002+01:00

You know you're a geek when the rental car company offers you a free upgrade to the 2012 Ford Mustang, and you agree primarily because you know it comes with a handy USB charger in the center console...

[You also know you're a Droid user when you're constantly on the lookout for ways to keep your phone charged].

Speaking at Oracle Open World - Tuesday October 4th in San Francisco

2011-09-03T22:34:00.003+01:00

It's not often I am on the same roster as Sting and Tom Petty, but at Oracle Open World I am. Admittedly Sting and Tom Petty will be performing to tens of thousands of people on Treasure Island, whereas I will be speaking at the much less dramatic setting of a Moscone Center auditorium the previous day.

My presentation is titled "Cloud Security Case Studies of SaaS, PaaS, and IaaS". The talk comes under the "Focus on Identity Management" list talks, and on that list I see a whole bunch of talks which I hope I will have the opportunity to attend. The conference is always very busy with many customers present, so that may be difficult, but I will try.

If you're going to be at OOW, please let me know, and I hope to see you there!

CRLs and browsers, and how a Gateway can help

2011-09-02T04:45:00.001+01:00

Zack Epstein reports on the DigiNotar certificate breach, noting that:

The compromised certificates have all revoked by DigiNotar, but not all Web browsers check for revoked certificates so the impact of this breach will likely be ongoing for some time.
http://www.bgr.com/2011/09/01/ssl-certificate-breach-extends-beyond-google-over-200-certificates-compromised/

It is an understatement to say that "not all Web browsers check for revoked certificates". Very few do. If you're using Firefox, take a look at Tools -> Options, then under the Advanced tab (not the "Security" tab as you might expect) click on "Revocation Lists". How many Certification Revocation Lists (CRLs) are listed there? Zero, right? Hint: You can add some CRLs from Verisign by clicking on the links on this page: http://www.verisign.com/repository/crl.html

Newly minted browser versions have the problematic certs removed from their trust lists. But, if browser manufacturers made it easier for people to use CRLs by default in their browsers, then that would not matter.

But are people really likely to manually add these CRLs? Probably not. Users should not have to know about the difference between the root certificate trust list in the browser, and a CRL. All of this conspires to make security hard for users.

A Gateway can help. When web traffic passes through a Gateway, it can check the CRL lists, and disallow traffic to a host using a revoked certificate. In the Vordel Gateway, configuring CRL checking is a matter of dragging-and-dropping CRL filter onto the canvas of a default policy. Now it checks the SSL certs against the CRLs, without changing anything on your users browsers. With the current situation where setting up CRL checking in a browser is not there by default, and way more complex than it needs to be, a Gateway is a pragmatic solution to address this problem.

Enabling Single Sign-On across Hybrid Clouds Managed by VMware vCloud Director 1.5

2011-08-30T17:32:00.002+01:00

We're very excited here at Vordel to announce, around VMworld 2011, that Vordel provides the capability to seamlessly log users into Cloud-based systems managed by VMware vCloud Director 1.5.

Single Sign-on is one of those things where the user's point of view is very different from the implementer. From the user's point of view, it "just works". A user logs in, clicks on a link, and does not have to log in a second time. From an implementer's point out view, there is a whole raft of underlying technologies in play. This Single Sign-on functionality which Vordel provides for VMware vCloud Director makes use of the long of identity management integrations provided by Vordel, including: CA SiteMinder, Oracle Identity Management, RSA, Entrust, Microsoft ADFS, and many others. But all of that underlying technology is in order to enable simplicity for the user.

Read more about it here:
http://vordel.com/news/press/30_08_11.html

Cloud Computing webinar presentation... using the Cloud

2011-08-30T17:18:00.003+01:00

I'm listening to Wolfgang Kandek (CTO at Qualys) give an excellent overview of Cloud Computing on today's webinar series . I am speaking in an hour's time on this same series. Take a look at how Wolfgang is showing his presentation, in the screenshot below. Notice something? It's itself using the Cloud itself: Using Google Apps. Not Powerpoint. The cloud even permeates my desktop below, since I am running a VMware Micro Cloud Foundary VM in VMware Player. Many times when we talk about a trend, there can be a certain amount of hype. But in this case, it's very real since we're all using the Cloud, even for a presentation about the Cloud :-)

Upcoming webinar with Qualys and CSA: "Cloud Computing: Security, compliance and Implementation Aspects"

2011-08-29T13:14:00.009+01:00

I'm speaking on a webinar tomorrow (August 30) alongside Wolfgang Kandek from Qualys and Steve Markey from the Cloud Security Alliance. The topic is "Cloud Computing: Security, compliance and Implementation Aspects". The full session starts at 12pm Eastern and my section is at 1.30pm Eastern. The topics we're covering are:

■Who owns the Security problem?
■What Cloud Computing security aspects should you consider?
■What is the purpose of these cloud computing security aspects and which solutions are available?
■Will I still be in control of the cloud computing security aspects?
■How about Cloud data assurance and compliance?

Table of Speakers:

Wolfgang Kandek: Chief Technical Officer at Qualys

---

Steve Markey: Chapter Officer at Cloud Security Alliance (US)

---

Mark O’Neill: CTO at Vordel and author of book "Web Services Security"

Sign up here: http://web2present.com/upcoming-webinars-details.php?id=10

Request throttling and concurrent connection throttling

2011-08-24T08:56:00.002+01:00

My colleague Ian Marsh has a really useful new post on request throttling and concurrent connection throttling (not the same thing, as Ian explains). Check it out, it includes info on how the Vordel Gateway works with an Oracle product for providing a non-blocking lock on the count of concurrently executing requests: http://enterprisegateway.wordpress.com/2011/08/23/throttling-a-variation/

Lightning strikes the cloud (or does it?)

2011-08-12T12:52:00.002+01:00

Silicon Republic covers the recent outage at Amazon's Dublin (EU-West) data center for Amazon Web Services. Initially it was blamed on lightning, but it looks like that was not the full story:

In the hours following the incident, Amazon originally blamed a lightning strike and an explosion which knocked out a generator leading to loss of power, which disrupted service for Amazon customers for up to 48 hours in some cases.

Electricity provider ESB Networks has provided a different version of events. A spokesperson told Siliconrepublic.com that the problem was due to a fault in one of its substations at Citywest and that power would have been available from an alternate source within a millisecond.

http://www.siliconrepublic.com/strategy/item/23084-mystery-surrounds-outage-at/

A second chance to catch the "Bridging Security from the Enterprise to the Cloud" webinar

2011-08-11T17:24:00.006+01:00

Missed the "Bridging Security from the Enterprise to the Cloud" webinar earlier today? Watch it below:

A BrightTALK Channel

Upcoming Webcast - Bridging security from the enterprise to the cloud

2011-08-10T01:53:00.004+01:00

This Thursday there is not one but two Vordel webinars, one on BNSF's migration of their Cisco Ace XML Gateway (AXG) appliances to Vordel, and one on how to bridge security from the enterprise to the cloud.

I've already blogged about the first webinar, which will cover the process by which BNSF (Burlington Northern Santa Fe) Railway chose Vordel to replace its Cisco AXG gateways. So here's the scoop on the second one:

In the "How to bridge security from the enterprise to the cloud" webinar, I'll be talking about the pattern of "bring your own identity" for Cloud access. We are all familiar with leveraging existing identities (login with Facebook, login with Google ID) for cloud-based apps. In the enterprise world, the challenge is to allow employees to leverage their existing on-premise identities, such as their logins into Active Directory or other IdM (identity management) infrastructure. It is "bring your own enterprise identity". This is an important aspect of what it means, in practice, to bridge security from the enterprise to the cloud.

Follow this link to register, and look forward to seeing you on the webinar this Thursday: http://www.brighttalk.com/webcast/679/32827

How to filter SOAP MTOM/SWA attachments in the Vordel Gateway

2011-08-03T13:32:00.009+01:00

Filtering SOAP attachments is something which is a very common feature implemented on a Gateway such as the Vordel Gateway. Here is a step-by-step guide to how to set this up:

If you've already registered a WSDL, skip forward to step 4.

Step 1: Open the Vordel Policy Studio. Connect to the Gateway you wish to configure your policy on. Either connect directly or login through Policy Director (which allows you to push configuration to multiple Gateways at once).

Once you connect, choose "Edit Active Configuration".

You will see the screen below. New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.

Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups.

Step 3: Select your WSDL (either via URL, file, or UDDI) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in the Vordel Gateway, but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface, such as SSL (create the new services, then right-click and choose "Add interface"). You can even add a JMS listener, or a file folder scanner.

Don't check the box right now to "Secure this Web Service". You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that the Vordel Gateway will automatically virtualize the service hostname in the WSDL.

Step 4: Right-click on "Policies" in the Vordel Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.

Call your new policy "Filter Attachments"

Step 5. Drag in a "Content Type" filter, which you can find in the "Content Filtering" group. We are filtering the message based on its content type. Configure it as shown in the screenshot below, where only XML and PDFs are allowed (i.e. a SOAP/XML message with a PDF attachment).

Note that you must have "multipart/*" selected also, because that is used by the SOAP-with-Attachments standard to deliniate attachments. If you have not got this selected, all SOAP attachments will be blocked (note: this may be intended in some use cases).

When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the message itself) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.

Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for ''. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to filter attachments. Once it is mapped, you should see the mapping set as in the screenshot below.

Make sure you press the "Deploy" button on the Studio toolbar to deploy this policy.

Step 7: Open SOAPbox (grab your free copy from Vordel). We will be using SOAPbox to test our attachments policy. Open the Virtual Service WSDL which you obtained from Step 3. [Tip: The Service Manager interface, under :8090/ , also allows you to see the Virtual Service WSDL, if you connect with a role which allows you to use Service Manager]. In SOAPbox, press on the import WSDL and import the Virtualized WSDL (note: not the actual WSDL from the back-end service you've registered, otherwise you'll simply send your messages to the back-end services and not through the Vordel Gateway).

Step 8: You'll see a sample message created for you in SOAPbox. Click on the "Attachments" tab on the botton of SOAPbox . Choose to add an attachment which is not allowed (i.e. something other than a PDF, since in Step 5 you chose that a PDF was the only allowable attachment. Send the message through to the Vordel Gateway in SOAPbox, by pressing the green triangular "play" button. These steps are shown in below.

The message will be blocked. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.

Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring (e.g. an "operator" or "auditor" role):

Step 10: Import the WSDL into SOAPbox and send it through the Gateway without the SOAP Attachment. Note that SOAPbox allows you to have multiple messages saved, which you can see if you click on the small down-arrow button beside the green "play" button, and choose "Request Settings".

Other steps: Note that the Vordel Gateway includes a filter called "Remove Attachment" which you can use to remove attachments. You may use it similar to the process outlined above. In addition, the Message Size filter will block large messages based on (optionally) attachments as well as the message itself.

Enter the Entitlements Server

2011-08-02T13:49:00.004+01:00

It is always striking that so much work is done on authentication technologies, but so little on authorization. Usually authorization (the decision on "who can do what") is baked into code in applications. This makes it difficult to change these rules later, or to audit the rules. Entitlements Servers fill this gap, by externalizing authorization from applications. Marc Chanliau has written a really useful article on entitlements servers, which provide this service exactly.

He gives a good example of when an entitlements server is vital:

Suppose a homegrown portal application must present a sensitive piece of customer information such as a Social Security Number (SSN) when a service representative views a customer's profile. It is determined that in order to ensure compliance with various privacy regulations, only directors and senior managers may be able to view a customer's SSN. A decision has to be dynamically made whenever the application must show an SSN as to whether the current user may view the actual data or some default value (e.g., "XXX-XX-XXXX"). The decision must take into account the user's job title. A dozen parts of the application that can display a customer's SSN mean a dozen places for this business logic to be applied.

Now assume that the policy needs to be changed after the application has been in production for some time. The business has determined that senior managers in California may not view an SSN. This is an exceptional situation that requires another piece of information to be considered as part of the entitlement decision. But what if we take the example even further? Suppose that only directors above a certain salary grade can view SSNs. Now the entitlement logic has been split into multiple decisions based on runtime attributes. So the business logic must be adapted.

You can see that authorization or entitlement policies evolve very differently from application requirements. Having the entitlement logic "hard wired" into the business logic means changing code each time there is a policy change.

http://soa.sys-con.com/node/1923919

He then goes on to explain how an Entitlements Server works in the framework of RBAC (Role-Based Access Control) and the PEP/PDP/PIP model. Gateways like the Vordel Gateway are often deployed as the PEP part of this model, and I've written recently about the benefits of integration between the PEP and the Entitlements Server.

Rock 'n' Roll

2011-08-01T14:13:00.002+01:00

Here is a section from Prince's rider for a recent concert (scroll down to the bottom of the article). I guess Prince is a fan of Windows (and Google):

Please provide a laptop computer (Windows Operating System) with large screen in the suite.
Please have the computer powered on with the web browser displaying the Google home page.
High-quality flower arrangements in suite

Job posting: Vordel, Oracle, and CA SiteMinder skills in San Diego

2011-08-01T13:29:00.005+01:00

Qualcomm in San Diego is looking for someone with Vordel, CA SiteMinder, and Oracle skills.

Vordel and Oracle Entitlements Server - The power of direct integration

2011-07-29T19:56:00.005+01:00

"Interoperability" and "Integration" are two words which are often used interchangeably. However, in systems architecture they have different meanings. "Interoperability" means that products will talk to each other, usually over the network or through shared understanding of a file format. "Integration" means something closer.

In the case of Oracle Entitlements Server (OES), this distinction is important. In Oracle's OES Product White Paper, a number of Gateways are listed as being able to use OES to manage authorization for Web Services. i.e. "interoperability". But only two are mentioned as being able to have OES directly embedded into the Gateway:

"To reduce latency, OES can be directly embedded into XML Gateways such as Oracle Enterprise Gateway and Vordel."
http://www.oracle.com/technetwork/middleware/oes/oes-product-white-paper-405854.pdf

This direct embedding of OES into the Gateway is true integration. It reduces latency for customers, which is vital in environments such as financial transaction processing and telecoms. To see how this works in practice, check out the video below which shows how the enforcement of OES authorization policies is directly embedded into the Vordel Gateway:

How to configure XML Signature on the Vordel Gateway

2011-07-29T00:53:00.008+01:00

Validating XML Signature is relatively simple to setup on the Vordel Gateway. Here are the steps:

Step 1: Open the Vordel Policy Studio. Connect to the Gateway you wish to configure your policy on. Either connect directly or login through Policy Director (Policy Director allows you to push out policies to a number of Gateways at once).

Once you connect, choose "Edit Active Configuration".

You will see the screen below:

New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.

Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups. In the screenshot below you can see that we've created a group called "B2B Web Services" and one called "Internal Web Services".

Step 3: Select your WSDL (either via URL, file, or use the UDDI interop with registries such as HP Systinet) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in the Vordel Gateway, but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface (create the new services, then right-click and choose "Add interface").

Don't check the box right now to "Secure this Web Service" (that's what we'll do next). You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path, but note that you can always see it again by right-clicking on the service and choosing to "Quick Edit" it. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that the Vordel Gateway will automatically virtualize the service hostname in the WSDL.

Step 4: Right-click on "Policies" in the Vordel Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.

Call your new policy "Validate Signature"

Step 5. Drag in a "XML Signature Verification" filter, which you can find in the "Integrity" group in Policy Studio [tip: in the searchbox above the list of filters in Policy Studio, start typing "Signature" and it will narrow down your choices to just those which include signature functionality). Configure it as shown below:

When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the messages) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.

Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for ''. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to do Signature Validation. Once it is mapped, you should see the mapping set. Make sure you press the "Deploy" button on the Studio toolbar to deploy this policy.

Step 7: To test this service, we'll use SOAPbox, which is Vordel's free Web Service testing tool. We will import the Virtual Service WSDL which you obtained from Step 3. In SOAPbox, press on the Import WSDL button (on the toolbar) and import the Virtualized WSDL from the Gateway.

Step 8: You'll see a sample message created for you in SOAPbox. Send the message through to the Vordel Gateway, by pressing the green triangular "play" button on the toolbar of SOAPbox. This message will be blocked because it has no signature. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.

Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring. The screen is shown below:

Step 10: In SOAPbox, choose "Security" then "Sign Request" on the menu. Under "Signing Key" you can simply choose the sample key which ships with SOAPbox (called "CN=SOAPBoxConfig"). Under the "What to Sign" tab, choose the "Xpath" sub-tab and then choose "The SOAP 11 or SOAP 12 Body". Leave the other settings as they are, and press "Finish". You should now see the signature in your message in SOAPbox. Send the signed message through and it will be validated successfully , as shown below:

Other steps: In Studio, note in the "certificates" group that you can then check the trust of the certificate from the signature (i.e. check that its issuing CA is trusted). you can also validate the certificate against a CRL, an OCSP responder, or an XKMS service. To do these steps, drag one or more of these filters after your Validate XML Signature filter and drag a green line from the Validate XML Signature filter to it, indicating that you wish to check the certificate after you have checked the signature. Note that the "certificate" attribute is populated after the signature filter runs, and it then is passed to the certificate validation filters which require it.

Signing and inserting SAML Tokens at the Vordel Gateway for Oracle OSB

2011-07-28T02:35:00.002+01:00

Oracle OSB embeds the Oracle OWSM functionality for security features such as SAML and WS-Security. When using a Gateway in front of Oracle OSB, it is important to configure it so that the Gateway inserts and signs SAML tokens in such a way that Oracle OSB can successfully consume them. Usually the simplest way to do this is to import the WSDL of the service into the Vordel Gateway, and it will see the "advertised" WS-Policy inside the WSDL and kick off the wizard setup the appropriate policy. But if you find yourself setting this up manually, here are the details:

1) Insert the SAML Token and choose SAML Version 1.0 (assuming that is what is being expected at the OSB side), Sender Vouches, and choose to not insert the SAML Token into a Security Token Reference (STR). [the STR is made at the signing point, which comes next...].

then...

2) Sign the SAML Token, and under "What to Sign", choose "Use WSU Ids", "Use SAML Ids for SAML Elements", and "Add and dereference Security Token Reference for SAML". Under "Node Locations" in "What to Sign" choose the SAML 1.0 assertion and the SOAP body. Under "Signing Key" and "Key Info" choose "x509vs", and "include TokenType".

This works great and allows a SAML token to be used to propagate identity from the Vordel Gateway through to Oracle OSB.

Mapping the Cloud: Cisco ACE upgrade to Vordel Gateway

2011-07-22T17:03:00.005+01:00

Vordel is presenting a webinar next month about how BNSF Railway upgraded their Cisco ACE XML Gateway to the Vordel Gateway. We're pretty excited about this, and it looks like other people are, because it's been retweeted a lot.

One particular tweet piqued my interested, and I click on it. It's the tweet below:

CloudWebinars provides a useful service on Twitter by placing upcoming cloud webinars into Google Calendar. So, when I clicked the link, I noticed that the calendar entry links to a map of where the webinar is located. I could not resist clicking on the Map link below. I was wondering "How would Google map the Cloud?"

And sure enough, when I clicked on the link, I see that Google tries to map where "The Cloud" is located in Boston:

But, rather than following Google's attempt to locate The Cloud in Boston, here's the correct link :-)
https://www2.gotomeeting.com/register/741348594

How to convert XML to SOAP on the Vordel Gateway

2011-07-15T23:10:00.006+01:00

When you think about converting XML in general, it's natural to think "use XSLT". But it's important to note that the Vordel Gateway actually supports conversion of XML to SOAP out-of-the-box without having to resort to using xslt. Simply use a "Set Message" with a SOAP Envelope and inside the SOAP Body put a ${content.body} attribute and then the incoming XML will be automatically placed into a SOAP envelope on-the-fly. Like this:

... and, as they say in the UK, "Bob's your uncle".

But if you want to do this using an XSLT transformation, here is one you can use (import it using the "Stylesheet Conversion" filter):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<xsl:text disable-output-escaping="yes">
<</xsl:text>SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<xsl:text disable-output-escaping="yes">></xsl:text>
<xsl:text disable-output-escaping="yes"><</xsl:text>SOAP-ENV:Body<xsl:text disable-output-escaping="yes">></xsl:text>

<xsl:copy-of select="*" />

<xsl:text disable-output-escaping="yes"><</xsl:text>/SOAP-ENV:Body<xsl:text disable-output-escaping="yes">></xsl:text>
<xsl:text disable-output-escaping="yes"><</xsl:text>/SOAP-ENV:Envelope<xsl:text disable-output-escaping="yes">></xsl:text>
</xsl:template>

</xsl:stylesheet>

How to configure Throttling on the Vordel Gateway

2011-07-14T09:02:00.004+01:00

Here's a guide to setting up throttling in the Vordel Gateway:

If you've already registered a WSDL, skip forward to step 4.

Step 1: Open Policy Studio. Connect to the Gateway you wish to configure your policy on.

Once you connect, choose "Edit Active Configuration".

New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.

Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups. In the screenshot below you can see that we've created a group called "B2B Web Services".

Step 3: Select your WSDL (either via URL, file, or UDDI) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in , but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface (create the new services, then right-click and choose "Add interface").

Don't check the box right now to "Secure this Web Service". You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that will automatically virtualize the service hostname in the WSDL (as explained here: http://www.soatothecloud.com/2011/06/how-to-enable-service-virtualization.html ).

Step 4: Right-click on "Policies" in Policy Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.

Call your new policy "Throttling"

Step 5. Drag in a "Throttling" filter, which you can find in the "Content Filtering" group. Configure with "10 messages in 1 minute" as shown in the screenshot below. Note that the Gateway must retain state for the messages, because it stores the message count. So, this is stored in a cache [called "Maximum Messages" in the screenshot]. You can add another cache, or edit the cache name, under "External Connections" in Policy Studio.

When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the messages) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.

Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for ''. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to do throttling. Once it is mapped, you should see the mapping set. Make sure you press the "Deploy" button on the Policy Studio toolbar to deploy this policy.

Step 7: Open the SOAPbox testing tooll (a free download from here) . We will be using SOAPbox to test our throttling policy. Open the Virtual Service WSDL which you obtained from Step 3. [Tip: The Service Manager interface, under :8090/ , also allows you to see the Virtual Service WSDL, if you connect with a role which allows you to use Service Manager]. In SOAPbox , press on the import WSDL and import the Virtualized WSDL (note: not the actual WSDL from the back-end service you've registered, otherwise you'll simply send your messages to the back-end services and not through ).

Step 8: You'll see a sample message created for you in SOAPbox. Send the message through to with SOAPbox, by pressing the green triangular "play" button. Keep pressing the button until you reach the throttling limit. This message will be blocked. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.

Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring. The screen is shown in the screenshot below:

Other steps: If you add a Distributed Cache (under "External Connections" then "caches" then "Add" in the botton-right) then you can set two or more Gateways to use the same cache. This means that if the traffic is being distributed across them, then the throttling count is cumulative over them (e.g. if 5 requests come to 1, and 5 to 2, then the value in the cache will be 10).

Getting started with the Vordel Gateway

2011-07-11T16:11:00.002+01:00

My colleague Ian Marsh has written some really useful blog posts about how to get started with the Vordel Gateway, including the ubiquitous "Hello World" and then some really useful pointers to how to create policies inside the Gateway. Definitely useful and worth following Ian over at http://enterprisegateway.wordpress.com/

OAuth, SAML, Query APIs, oh my - Finding the right Cloud integration standard

2011-07-08T06:28:00.004+01:00

I've written an article for SD Times about the proliferation of standards for Cloud security. In the article I mention the Amazon Query API method of authentication, which although not an actual standard, has become something of an "industry standard" for authentication to Cloud-based APIs. It is widely used, not least for Amazon's own APIs of course.

The article didn't allow space for message examples, but here in this blog I can show an example of the Amazon Query API. This request is generated by a Vordel Gateway, acting as a client in this case. You can see that the request contains an "Authorization" header which is an HMAC signature computed over data including the URL, the timestamp, and the nonce ("number once" - a value which changes with each request, to combat capture-replay attacks). The signature is created using a shared secret key. An advantage of the Query API is that it is *much* smaller than using XML Signature, for example. It is also RESTful, because the request is a regular HTTP POST with the parameters passed as HTTP parameters. In effect it mimics a HTML Form POST. Here is the example below:

GET /ProcessAPIRequest HTTP/1.1
Connection: keep-alive
Transfer-Encoding: chunked
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
timestamp: 110708054739159GMT
Nonce: Id-0000013108497d0e-0000000001bed3d1-57
encryption_type: HmacSHA1
client_ref_id: client
Authorization: MGJ4aVdxeTIwWXltNTNSSUIvQW9vT2xOOE1BPQ==
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Via: 1.1 Dell-PC (Gateway)
Host: 127.0.0.1:7071
Content-Type: application/x-www-form-urlencoded

firstname=fname&lastname=lname&id=xyz

Halt: Who goes there? [... and what are their attributes?]

2011-07-01T06:42:00.004+01:00

Access control is not only about identity, it's also about attributes. In the government/defense area, an access control decision may be made on rank, for example. A rank (e.g. an army captain) is an example of an attribute.

These attributes have to come from somewhere, and thanks to hard work by Anil John and others, there is a specification explaining how to look up these attributes. Vordel implements this specification, which is called the BAE (Backend Attribute Exchange) profile. Anil has a write-up on BAE v2 here, including how it uses SAML and SPML. If you're interested in seeing a demo of how Vordel implements BAE, give us a shout on info@vordel.com. We're proud to implement this spec which makes access control more "joined up", and always happy to show it in action.

How to enable Service Virtualization across hosts

2011-06-21T15:16:00.005+01:00

One of the core patterns for a Gateway is "Service Virtualization". Service Virtualization means that an organization can expose virtual services in front of its infrastructure. These virtual services can take the form of lightweight REST APIs or heavyweight SOAP Web Services. The Service Virtualization pattern enables you to do neat things, like expose a REST service in front of a SOAP service, and convert REST to SOAP dynamically at the Gateway. You can also use the Gateway to deploy a virtual service in front of a database, or a message queue, or an ESB.

But how does it work? The answer comes down to how the virtual service is advertised to the client. Remember that service interfaces are generally advertised using WSDL (and as of WSDL 2.0, this applies to REST API interfaces as well as SOAP). WSDL includes the address of the service provider host. When the Gateway exposes a virtual service, it must replace this address with the address of the Gateway. Otherwise, clients would simply try to connect to the back-end service, thus attempting to bypass the Gateway.

Here we see an example where the client is pulling down the WSDL of a virtual service from the Vordel Gateway. Notice that the address of the service has been changed to the address of the Gateway:

But what if a client from the outside world accesses the virtual service, via a public Fully-Qualified Domain Name like services.mycompany.com ? Will the WSDL still say "VordelGateway" in it? If so, this would not work.

A neat feature of the Vordel Gateway is that it dynamically virtualizes its services based on how the client calls it. So, when we call the virtual service using the hostname services.mycompany.com , this is what happens:

Notice that the Vordel Gateway has dynamically virtualized the service with the hostname used by the client. If we'd pulled down the WSDL by its IP address, it would have placed the IP address in there. This is a very neat feature.

The SSL-savvy of you may be thinking "hmm.... those WSDL addresses use SSL but that's going to throw a warning if the hostname changes, and it'll also cause some Java clients not to connect". Well, that points to another neat feature that enables Service Virtualization. The Vordel Gateway implements SSL Server Name Identifier (SNI) which means that when it's called using a particular hostname, it will dynamically use the appropriate SSL certificate (and private key) for that connection. If you right-click on an SSL interface in Policy Studio, you can see this:

Notice in the screenshot above that there are two certificates set. Both must have corresponding private keys (since that's essential for SSL). When the Gateway is called using the name "vordelgateway", it assumes identity "CN=VordelGateway" (CN means "Common Name", in X.509 Certificate jargon). When the Gateway is called using "services.mycompany.com", like in the second screenshot above, it assumes identity "CN=services.mycompany.com". This is all done on the fly. Without this feature, many clients would not connect because the SSL certificate would not match the hostname. But with this feature, it "just works".

For more info, you can register for a live demo of the Vordel Gateway at: http://www.vordel.com/demo.html

The value of an Audit Trail for blocked REST API calls

2011-06-06T15:48:00.004+01:00

An often-overlooked aspect of security is the Audit Trail. In the case of a REST API, we want to know not only that a REST API call was blocked, but why it was blocked.

Let's take a look at the Real-Time Monitoring from the Vordel Gateway, deployed to manage a REST API. We see the orange spike indicating that an API call was blocked:

The key to looking up the Audit Trail is the message ID. Vordel users will be familiar with this ID as the ${id} attribute which is automatically created for each message in the Gateway. In this case, I highlight the message ID for the offending message and copy it:

Then I tab over to the Audit Trail and paste the Message ID into the search form:

When I press the Search button, I can see the message content, including the SQL Injection attempt which I have circled. The Vordel Gateway detected and blocked this attack against the REST API.

So, it's important to know not only that a REST API call was blocked, but why it was blocked and what the REST API call actually was. This is the value of an audit trail. In addition, the Audit Trail logs may be signed, and the key used to sign them may be stored on a HSM (Hardware Security Module). All of the screenshots were taken from the Vordel evaluation image, which you can request from info@vordel.com

The REST Doggy Door

2011-06-05T07:05:00.004+01:00

It's often a good thought experiment to read something with a "developer" hat on, and then read the same thing with a "security" hat on. There is a classic example of this in a comment today on the Service Oriented blog:

REST is so simple to implement, that its like a doggie door... something that will let anything in, when you want to provide open interfaces. When you don't know what you're going to be hooking up, REST is good!
http://www.zdnet.com/tb/1-98110-1897138?tag=talkback-river;1_98110_1897138

A REST API is indeed a great way to allow a multitude of devices and apps to consume a service. Almost any app can create a simple HTTP GET and pass some parameters with it because, as people say, "it's just a wget".

But wait, what about security? In the doggy door analogy, what if a snake or, if you're in Florida, a lizard comes in through that doggy door? In the REST world, the snakes and lizards are malicious users, who want to use REST services for data-mining or denial of service. For this reason it is important that REST APIs are protected and managed. However, back to the doggy door analogy, it is just as important to not make that doggy door so complex that the dog gives up and goes elsewhere. In that case, you'd be locking the dog out with the snakes and lizards.

For all these reasons, REST API management has to enable the right apps and devices to connect, without placing onerous requirements on them. Remember that REST exists to be easy to use, so if you force clients to suddenly place honking great security assertions into each request, they will be turned off.

So what is the solution? I've written about the options for securing REST API's before, and I recommend checking out this 40-minute video explaining how REST APIs can be deployed safely. The key is to choose an authentication scheme which can be supported by the widest variety of clients, leveraging open standards and best practices. Wind the video on to minute 20 to see how the "REST doggy door" can be secured.

Projecting Identity to the Cloud - Cloud Expo New York

2011-06-05T02:03:00.000+01:00

I'm on the other side of the world, working with partners and customers this week on some pretty exciting stuff, so my colleague Isabelle Mauny will be ably giving the presentation on Single Sign-On to Cloud Services over in New York at the Cloud Expo.

So what is the reason for Single Sign-On to Cloud services? It's all part of "Bring Your Own Identity" (BYOI). BYOI is a major trend for Cloud services. Witness the many "Log in with Facebook" and "Log in with Google" buttons on sites like TripIt. In the enterprise, it's about "Identity Projection" where users log in as usual (e.g. with Active Directory, or to a corporate portal) and then are seamlessly logged into Cloud-based services such as a corporate Google Mail account. This means projecting your corporate identity up to the Cloud service. It's "Bring Your Own Corporate Identity". And Single Sign-On is what enables this.

The most obvious benefit of this is that is saves the user the hassle of keying in another password. That is a good benefit, but there are a lot more:

- As Nik Cubrilovic put it in his detailed treatise on the "The Anatomy Of The Twitter Attack", "Bad human habit #1: Using the same passwords everywhere. We are all guilty of it." If you ask users to log in to multiple services in order to get their work done, they will most likely use the same password everywhere. This provides an attacker with a "find once, use anywhere" approach to passwords. But if Single Sign-On is used, no password is ever sent up to the Cloud service. This is all part of the trend to minimize password use, for good reasons.

- It is costly to manage all those passwords. Over the years, it has been proven that password resets cost a lot of money. They waste productivity (users can't get to the information they need for their work), and tie up IT helpdesk people. As mentioned in the point above, in the Cloud world all those password resets create a security threat.

- Agility. The word is over-used, but in the case of Single Sign-on to the Cloud, it means that new Cloud-based services can be brought on-stream for employees (TripIt for travel management is a good example), without having to provision all those employees with new passwords.

I think that this "Projection of identity to the Cloud" is going to be an important topic going forward. The session is at 3.15pm on Wednesday June 8th at the Javits Center.

BYOA - Turtles all the way down

2011-05-31T09:05:00.000+01:00

Joe McKendrick has a post this week on BYOA: Bring Your Own App. He cites the example of Podio. It's effectively a way to create a mobile or Web-based app, without the need to learn programming. A very neat service, nicely executed. As Joe McKendrick notes, this has been a much-promised dream for a while now. But it's getting closer to reality.

He notes optimistically that:

IT managers can do what they do best — worry about scalability, uptime, security and standards compliance on the back end or in the backbone — and leave many of the use cases for users themselves to sort out.
http://www.zdnet.com/blog/service-oriented/byoa-and-productivity-is-build-your-own-app-now-a-reality/7084

I saw "optimistically" because of the worry many IT managers would have that BYOA is simply a way for employees to circumnavigate IT departments, and avoid their pesky concerns about security and standards compliance. But surely IT departments should embrace BYOA. How? By ensuring that the BYOA apps run through an on-premises Cloud Service Broker . The CSB layers on the attributes which may be lacking from from a BYOA app. These are rules for monitoring scalability and uptime (see the piece on "It's 4am - do you know where your Cloud provider is"), as well as security and standards compliance. And what about mobile BYOA apps that aren't run from inside the enterprise? Those BYOA apps can be run through a Cloud-based infrastructure, leveraging "reachback" into the enterprise, as described here in this webinar.

One fascinating aspect of Podio is how it is a Cloud app, itself built on a stack of Cloud apps (Amazon CloudFront, on Amazon Web Services, with Zendesk). So you can built your own BYOA Cloud app on top of a Cloud service (Podio), which itself is on top of Cloud services (Amazon's). It's turtles all the way down, and I think we'll see apps like this increasingly in the future. Clouds on top of clouds. Podio is on Amazon, so an Amazon outage affects it. Its customer management is with Zendesk, so ditto. A Cloud Service Broker can monitor and manage this.

By the way, the next trend? BYOI: Bring Your Own Identity. A future post on that...

CTOEdge - It's 4am, do you know where your Cloud provider is?

2011-05-31T03:00:00.000+01:00

I wrote an article about how to control for the reliability of third-party Cloud services. There is an old quote about distributed systems which I always think of, in relation to Cloud services:

...it is worth being mindful of the famous quote (by Leslie Lamport) that "a distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” In the case of an organization using cloud services, the failure of a computer you didn't even know existed and isn’t under your control and may not even be in the same country as you can render your business inoperable...
http://www.ctoedge.com/content/its-4-am-%E2%80%94-do-you-know-where-your-cloud-provider

Check out the article over at CTOEdge.

Alternatives to OpenSSL: How to graphically create an X.509 Certificate with a private key

2011-05-27T08:54:00.000+01:00

There are many ways to generate an X.509 Certificate, including using OpenSSL on the command line. However, mastering the OpenSSL command-line options can be tough for people who only need to create a certificate now and again. If you'd like a free tool which can an X.509 certificate graphically, no command-line needed, then take a look at the Vordel SOAPbox. It's a free download.

Once you download it, here is how to generate a certificate:

1) Go to the Security menu item, then "View Certificates"

2) Click on "Create/Import"

3) Click the "Edit" button and input the various attributes for your certificate (e.g. Common Name, stateOrProvinceName, countryName). Once you're done, press "OK".

4) Press "Sign Certificate" and choose whether you want to Self-Sign the certificate. Note that making a CSR (Certificate Signing Request) isn't an option in SOAPbox so you can either self-sign the certificate or sign it with a local CA certificate.

5) Then press "Export Certificate" to export the certificate as a .pem file. Or press "Export Certificate and Key" to export your certificate along with its private key (but note you'll have to enter a password for this, and remember the password).

Once you've done these five steps, you have your certificate. It's as simple as that.

Mobile reach, and reachback: Enabling Mobile Apps

2011-05-27T01:17:00.001+01:00

There was a lot of great interested in the webinar last week about enabling mobile apps, including a lot of discussion of the "Reachback" architecture which enables mobile apps to connect back into the enterprise apps, through a Cloud-based "border Gateway" as Scott Matsumoto put it.

I'm happy to say that the recorded webinar is now online, and you can view it here.

Webinar on 19 May - Enabling Secure Mobile Applications

2011-05-19T04:15:00.000+01:00

Tomorrow, 19 May, Scott Matsumoto from Cigital and I are presenting a webinar on the topic of secure mobile applications. In particular, we focus on the question of how to deploy mobile applications which must make use of internal systems behind the firewall. This is a common problem, since organizations understandably do not want to punch inbound holes in their firewalls. Additionally, the worlds of mobile apps (REST, JSON) and the enterprise world (SOAP/WSDL, message queues) must be bridged.

The webinar is at 12pm Eastern, Thursday 19 May. Register at the link below:

https://www2.gotomeeting.com/register/382089859

PCI-DSS for credit card payments with Vordel

2011-05-09T18:01:00.000+01:00

There is a new customer case study up on the Vordel website, explaining how the Vordel Gateway manages credit card data, supporting PCI-DSS, and providing monitoring in conjunction with HP. The case study is for Cetrel in Luxembourg.

Here is the background:

Cetrel had to create over 600 different Web Services to meet the many and varied needs of its individual customers.
Fine-grained and customized security controls (such as crypto settings for confidentiality and integrity) specific to each Web Service and customer needed to be replicated and enforced.
The new solution needed to be deployed without disrupting the continued delivery of the service and be able to go live into production within 4 weeks of delivery.
Cetrel required a solution offering a broad range of security policy support; ranging from existing legacy standards to the very latest versions of WS-Security policy.
The solution also had to be compliant with Mastercard and VISA rules and regulations (especially PCI-DSS) and be capable of integrating all relevant compliance amendments.
Reduce as much as possible the configuration changes required to the new backend system, keeping in mind that the rollout of customers will be completed over several months.
Finally, Cetrel required a solution offering very stable performance levels. Cetrel needs to be able to respond quickly at all times to any service outage. They sought a solution to monitor the Web Services traffic and that could report into their HP monitoring solution.

And here is the outcome:

With Vordel, Cetrel addresses all its technical concerns and is successfully delivering on its overall stated business objectives. Benefits derived from the Vordel Gateway appliance include:

An improvement in the overall performance and efficiency of the SOA infrastructure. The gateway is dedicated to the tasks of accelerating the processing of XML and other data formats and security protocols whilst the application server infrastructure is focused on processing business logic.
Easier and faster on-boarding of new customers via the flexibility of the security standards supported by the Vordel Gateway and versatility of applying different dedicated per user policies for the very same Web Service.
Improved operational efficiencies via the segregation of team duties; the application support team can focus on the business logic coding whilst the infrastructure support team can focus on security and monitoring.
Cetrel reduces the risk of security weaknesses via in-house development; now the developers can focus on business and functionality integration.

Speaking next week at the European Identity Conference

2011-05-04T14:02:00.000+01:00

I'm speaking next week on a panel at Kupinger Cole's European Identity Conference (EIC) in Munich. The session is entitled How to do Authentication for the Private, Hybrid, and Public Cloud - Secure, Unified, Flexible. Also on the panel are Judith Littel from CloudID, Travis Spencer from Ping Identity and Thomas C Stewart from SecureAuth. Sebastian Rohr from Kupinger Cole is moderating. It looks to be an interesting session and I'm very much looking forward to it.

Inaugural Boston Cloud Security Alliance meeting on April 27

2011-04-23T16:27:00.000+01:00

My colleague Josh has organized the first Boston CSA meet at CA's offices in Framingham next Wednesday at 6pm. There are two great speakers lined up: Bhargav Shah from KPMG will talk about risks and controls for cloud models, and Robert Levine from SENA Systems will talk about the impact of Identity and Access Management (IAM) on cloud computing (in the immortal words of Gloria Estevan, IAM "cuts both ways" with cloud computing, since you can host IAM in the cloud, but also use IAM to control access to cloud-based resources).

I suspect that some of the discussion at the CSA meet will focus on the recent travails at the Amazon Web Services datacenter beside Dulles Airport. How can such outages be mitigated? Lew Moorman of Rackspace said it's like the equivalent of a plane crash, which is alarming but doesn't call all of air travel into question. Where the air travel analogy breaks down is that a person can't travel on two planes at once. The large cloud customers like Netflix who spread their cloud usage across centers were not brought down. As Dan Lohrman says on the Govtech website, it's a reason "You need a backup for your cloud provider's backup". The big guys like Netflix were able to organize (and pay for) this spread. But this is difficult for the smaller guys, like Quora who were brought down, but it's a further pointer to a broker model where off-the-shelf brokers open up the "cloud of clouds" to the mass market.

See you next Wednesday!

Cloud Security Alliance blog - Protect the keys to you API Kingdom

2011-04-22T13:11:00.000+01:00

I've a new post up on the Cloud Security Alliance blog on how to "Protect the API Keys to your Cloud Kingdom". It talks about the Cloud Service Broker pattern, and how this can be brought to bear on the problem. I've tried to gear the article toward practical advice, because there is so much theoretical information out there on Cloud security. Check it out at:

http://blog.cloudsecurityalliance.org/2011/04/18/protect-the-api-keys-to-your-cloud-kingdom/

As goes the Cisco ACE XML Gateway, so goes the Flip

2011-04-12T16:42:00.001+01:00

Roman Stanek pithily tweets today that "The Flip flopped", and Cisco is discontinuing it (rather than selling the business unit, thus denying the opportunity to use the headline "Cisco flips the Flip"). I guess the irony is that, as Ars Technica reports, far from actually flopping, "the Flip was still holding its ground against competition like Kodak with its own line of small, pocketable video cameras. Pure Digital offered one of the cleanest and easiest to use non-phone video solutions."

So Cisco purchases and discontinues a product. Nothing fundamentally wrong with the product, but Cisco refocuses and does what it does best. It reminds me of the Cisco ACE XML Gateway, discontinued and being replaced by customers with the Vordel Gateway through the Cisco ACE XML Gateway Replacement Program. Cisco refocuses, customers still get the functionality through other means, and overall life goes on.

Getting your hands on Vordel 6.0.3

2011-04-08T16:29:00.000+01:00

Since I posted a video demo of the Vordel Gateway v6.0.3 a couple of days ago, I've been getting emails asking how to get a copy. I can confirm that the Vordel Gateway is, as my German-speaking colleagues say, verfügbar (meaning "available" in German, though the word sounds a lot less positive to non-German ears). The first step is to contact Vordel from this page. We'll show you a live demo (the next step from the video demo on this blog) and get you started with the Gateway. Happy Gateway-ing (if that is a word, in any language :~) ).

Steve Coplan from 451 Group on Vordel

2011-04-07T09:05:00.000+01:00

Steve Coplan, Senior Analyst with the 451 Group's Enterprise Security Practice, has produced a report on Vordel. Follow the link from his tweet.

Video: Registering and managing a Web Service: Vordel 6.0.3 in Action

2011-04-06T08:57:00.000+01:00

This demo shows the Vordel Gateway v6.0.3 in action, covering the common case of (a) Registering a service, (b) applying policies, (c) showing the Gateway in action enforcing the policies, (d) reporting on service usage, (e) showing why messages are blocked. Finally we see the Policy Studio in action, this is what is used to make and edit policies.

If you want to see more specific video demos, check out the demos of the Vordel Gateway working with Oracle Entitlements Server and Oracle Access Manager here.

Note: Increase to full-screen to see the detail (or, if you're using a phone or tablet, simply pinch and zoom the video to see more).

Webinar on SOA and Cloud auf Deutsch

2011-04-05T16:48:00.000+01:00

Last week Vordel ran a case study webinar with Badenia AG (a German bank) on SOA and Cloud security. The information is below (auf Deutsch), and here is a link to view the Webinar.

Webinar: Sicherheit bei der Verwendung von Webservices und XML

Es werden die wichtigsten Security Maßnahmen beim Einsatz von Webservice (XML) an einem Beispiel aus der Praxis, der "Deutsche Bausparkasse Badenia AG ", gezeigt.

Webservices (XML) werden immer häufiger eingesetzt! Hierbei wird zwischen der Inhouse Kommunikation und der über die Unternehmensgrenzen hinausgehenden externen Kommunikation unterschieden. Bei externer Kommunikation werden heute Firewalls verwendet, diese aber Schauen in der Regel nicht in die jeweiligen XML Ströme hinein und lassen eine Kommunikation zu. Bei der Integration von Backendservices wird üblicherweise auf Security Maßnahmen verzichtet, was zur Folge hat, dass die Risiken der Inhouse Kommunikation nicht identifiziert werden. Bei der Absicherung von Webservices (XML) wird am Beispiel des Vordel Gateways aufgezeigt das Security nicht einen Performance Verlust bedeutet. Eine wichtige Komponente ist der zentrale Policy Enforcement Point, der in Verbindung mit einem Zertifikate Store die XML Ströme absichern kann. Dabei besteht die Möglichkeit, mittels einer Script Engine, die Standard Funktionalitäten zu erweitern und Ihren speziellen Anforderungen anzupassen.

Die Deutsche Bausparkasse Badenia setzt für die Erfüllung ihrer Webservice Security Anforderungen bereits seit dem Jahr 2004 Produkte von Vordel ein. Inzwischen ist das Vordel XML Gateway zu einem zentralen Bestandteil der Anwendungssicherheit geworden, was zu einer guten Bewertung der Infrastruktur in mehreren Security Reviews führte. Im Webinar wird gezeigt, wie das XML Gateway in die bestehende Infrastrukturlandschaft integriert ist, und welche Policies für die Herstellung der Webservice Security konfiguriert wurden. Es wird anhand eines Beispiels aus der Praxis gezeigt, wie flexibel das Gateway an spezielle kundenspezifische Anforderungen angepasst werden kann.

Cloud API Single Sign-On at Cloud Expo in NYC

2011-04-02T22:01:00.000+01:00

In June I'm going to be speaking at the Cloud Expo in NYC on Single Sign-On to Cloud APIs. I'll be expanding on the points I made in my Cloud Security Alliance blog post back in February, namely that:

- API Keys must be protected (and an interesting side-note here is that HSM vendors have a lot to gain from this, as they have been in the key management business for years)

- A broker model allows you to use local sign-in (to a PC, or to a portal) and leverage this into sign-in to a Cloud service (such as Gmail).

- Standards such as SAML and OAuth are certainly important, but so are "de facto standards" like how Amazon's "Query API" authentication.

And, as ever, I believe that the most valuable part of a talk like this are practical case studies. I'll include a number, including an education provider using Vordel to manage Single Sign-On to Google Apps for its students, and an organization which needed to choose which access management options use for its API.

See you in New York!

Tip: Hostnames and Common Names

2011-03-31T17:42:00.000+01:00

In the latest release of the Vordel Gateway, v6.0.3, we added the option for the Gateway to check if a certificate's Common Name matches the hostname of the machine using it. What does this mean?

Sometimes internal machines are setup with SSL certificates which don't match their hostnames. Usually the reason is because the organization has bought a block of certs from Verisign, doesn't want to order more, and doesn't want to use self-signed certificates. So if you are putting the Vordel Gateway in front of a machine which (for one reason or another) is using an SSL certificate which doesn't match its hostname, then you can tell the Gateway to either (a) flag this as an issue with the service and block the request, or (b) ignore the problem.

The setting is under the "Remote Hosts" setting in Policy Studio, and the checkbox is "Verify server's certificate matches requested hostname".

APIs and Services come full circle

2011-03-30T11:19:00.000+01:00

Back in 1996 when I joined an EDI company as a programmer, the first thing a colleague did was put the definitive Windows API reference, Programming Windows by Charles Petzold, on my desk. At the time we programmed for Windows 3.1 (and for something called "DOS Windows" - don't ask...). Then Windows 95 and NT. I can remember the excitement in our small programming group when the 5th edition of "Petzold", as we called it, came out. This heavy tome was "The definitive guide to the Win32 API".

At the time, an API was understood as being for C++ or Visual Basic. MAPI (the Mail API for Windows) is a good example. At the time I would write EDI clients using ISOCOR products, and one in particular, Personal ISOTrade, implemented the MAPI API. So, with that product, all we had to do was implement that API to send EDI messages (EDIFACT and HL7) over X.400. I also did Java programming at the time, and used Java toolkits (e.g. J/Crypto which was a full-strength JCA/JCE implementation) but these were toolkits or implementations of interfaces, not quite the same as "APIs".

Fast forward ten years. Service Oriented Architecture principles took hold, even if the name "SOA" remained controversial. The notion of Services replaced APIs. You may still use actual programmatic APIs, but the understanding was that what you were really using is a service which shouldn't be tied to a particular language. This kind of thinking was liberating, and opened up all kinds of possibilities. Gradually the APIs could be exposed in a more widely-usable way. This is how we started to talk about "services" not "APIs".

Daryl Plummer put it well that "someone told me, “if you’re over 30 you call it an ‘API’, and if you are under 30 you call it a ‘service’”)

But then what happened? It came full circle. In 2011 when we talk about "API's", we mean Web APIs like the ones on this huge list of Web APIs. The kids are now talking about APIs again, but not in the way that we did 15 years ago. Take for example the USA Today Sports Salaries API. Are you interested in finding out how much a particular US sports player earns? Then this API will get the info, using a HTTP request and receiving the response in JSON or RSS (XML).

One big difference between the C++/VB APIs of old and the Web APIs of today is that API management and security wasn't something that was considered 15 years ago. There were exceptions, such as crypto APIs which included controls against attackers swapping in their own implementation of the API as an attack. But mostly the APIs were called under the context of the user's application, and security was at that level (i.e. "The user must have logged in to use the app"). And usage of the API was usually not tracked.

But now, API management and security is important. To see why, check out that USA Today Sports Salary API page again. Access to this API is managed using an API Key:

Every call to the USA TODAY Salaries API must be authenticated with the programmer's unique API key, as in this sample request.
http://api.usatoday.com/open/salaries?api_key=XXXXXX

USA Today uses this developer key to limit access to their valuable sports salaries database to just 1000 requests per day. However, the API key in the example above is sent over (yikes) plain HTTP, so an imposter could sniff someone else's API key from a message and then use it to suck down sports salaries on their account. All of this points to the need for API management and security. Fortunately there are options for API security, so that exposing a Web API doesn't have to mean hanging your data out for the world to access over plain HTTP. With a service gateway it is quite trivial to create a policy that enforces SSL, enforces usage limits, and provides API monitoring.

One of my favorite Web APIs to use in demos is SalesForce.com . SalesForce has a ton of information about their API on their developer site. Vordel can be used to connect up to SalesForce, including protecting API Key and caching the Session Identifier which is returned back by SalesForce.

One of the neat things about this is that all traffic from the app to the SalesForce API is now authenticated and monitored, and shown in the browser, as shown below:

This type of API usage monitoring wasn't possible with the APIs of the past.

So APIs and services have come full circle. 15 years ago, it was all about APIs. Then it was all about services. Now, we talk about APIs again, but mean something different than we did back then. Security and management of these new APIs has reared its head, but the good news is that there are solutions to this.

Speaking XACML

2011-03-29T11:59:00.000+01:00

Over the past few weeks Gunnar Peterson has been running an interview with Gerry Gebel and his colleagues from Axiomatics, and now he's on to Part 3 of the conversation. I've known Gerry since his Burton Group days, and I know the importance he places on products natively speaking XACML (at Vordel we support XACML, but we also support native AuthZ connectors too). But I didn't realize that Gerry himself speaks XACML. As in, verbalizes is in conversation. In the interview below, Gerry doesn't skip a beat in moving from English to XACML. I'd love to hear a recording of the conversation. I wonder did Gerry say "In terms of XML schema, it is defined as follows: Open angle bracket, xs, colon, element, space, name equals quote attributedesigner (all one word), space type..." :~)

Beyond security - Monitoring and diagnosis

2011-03-28T23:27:00.000+01:00

It is often thought that one of the chief benefits of a SOA Appliance is security. Well, security is vital, certainly, but on a day-to-day basis a SOA Appliance is mostly used for keeping track of service usage, and for diagnosing problems with client messages. Security is taken as a given, but the monitoring provides immediate actionable information which helps clients troubleshoot their messages, and allows service providers to tailor their offerings. It also provides a path towards billing for web services, turning applications into profit centers.

Following up from yesterday's video, here are some pointers to using Vordel Reporter for monitoring service usage. In the screenshot below, you can see the client Web Service usage lookup, showing how our clients (in this case "East Industries", "Central Industries", and "West Industries") have been accessing services through the Vordel Gateway. The information is shown simply as totals, but if you want to see running graphs, hit the "clients" button (to choose clients to view) then the "Aggregated Metrics" button:

See the "Audit Trail" button in the top-right? Click on this to construct queries over Vordel Reporter. Let's say an admin from East Industries is on the phone saying "Why did you guys block our message?". You can construct a search to find out if East Industry's messages are falling foul of Schema Validation, indicating a problem with their messages. In the search results below, we see that is indeed the case:

When we double-click on one of the messages, we see the message itself, and the path it took through the policy on the Vordel Gateway. We see that East Industries was authenticated, but then their message failed Schema Validation. For good measure, we see the message in the report, which we can then download and test using the SOAPbox testing tool.

The upshot is that the organization can troubleshoot their client's messages quickly and easily. This is one of the key day-to-day benefits of a SOA Appliance. If you want to schedule a live demo of this feature in action, you can do that on the live demo page on the Vordel website.

Searching the Vordel Reporter Audit Trail

2011-03-25T05:35:00.000Z

Vordel Reporter is used to view usage of Web APIs and SOAP services. It is a Web-based tool, so there is nothing to install. API and service response times are shown, as well as information on which clients are using the services.

One of the neat things about Vordel Reporter is that you can drill in on messages and see the same kind of "Path through the policies" information as you see in the Vordel Gateway's Real-Time Monitoring. In the video below, I first run a report to see the clients which are accessing my services through the Vordel Gateway. Then I drill in on the Audit Trail, to see which messages from particular clients are failing schema validation, and I can take a copy of the messages themselves. The Message IDs allow me to cross-reference with the Vordel Gateway trace files. In the example, I'm checking to see which messages from "East Industries" have failed Schema Validation, and then I click on the message to see how it was processed in the Gateway. The neatest piece is at the end: The pass through the policy in the Audit Trail maps to the path through the policy shown in the Gateway's Real-Time Monitoring.

(Note: Click on the little "expand full screen" button by the video below so that you see the detail properly):

Using SOAPbox for XPath Injection

2011-03-16T04:48:00.000Z

XPath Injection is an attack which is applied to applications which consume XML. It attempts to subvert XML processing by injecting XPath, similar to how SQL Injection works.

You can use the free SOAPbox testing tool to test for vulnerability to XPath Injection. This is configured in the Design Mode of SOAPbox, as shown below:

Great Customer Service

2011-03-07T14:19:00.000Z

At Vordel we pride ourselves on great customer support, providing 24-hour phone and email service, our Vordel support portal filled with solutions, and valuing comments like this from customers. We also know that our products are used for important tasks, like monitoring shipping and signing doctors into medical records. However, try as we might, no vendor can approach the level of fanatical appreciation displayed by Apple customers, as this classic comment yesterday on Forbes.com shows. Not only do Apple products help this guy with his home lighting and home security, and cause him to not care one iota about more RAM or faster processors (but still fork out cash for the new faster products anyway), but he actually conceived a child with an app:

Thing is, there are apps I can only get from the app store that control my home lighting, and my home security. I own hundreds of apps that help me through out my work day. Also, I use my iPhone to project family pictures or videos on to my TV screen through the air and on top of that every time I have ever had any kind of issue with Apple, when I call them, they not only make it right, they go the extra mile. There store staff is trained and friendly and all my books, music, and movies, all sync so easily with my iPhone and iPad. Why would I ever want to switch to a different tablet. And Steve Job's job is to come out and be a salesperson. Sales people always tell you what you want to hear. Why would they come out and say something negative like, "And RAM, well, it just stays the same." That would be plain stupid. So who cares? The specs are clearly on the the Apple website. I have a child because of an app and we had been trying for two years. I guess what I am saying is. With my iPhone, iPad, and iTouch, they have always been fast enough for me. I have had every single one of the iPhones since they first came out. I don't need a faster processor or more RAM. Granted, I do feel that the product is faster when I get a new iPhone but ...I would have never known how that felt until I had the new one in my hand. So all of that is just icing on the cake. I love my iPhone because it comes with great customer service, is a well made product, and ties my whole life together very easily and is very easy to use. A kid can use an iPhone. Why would I switch? I have no problems and a great product that works perfectly. It is obvious that this guys just wants to hate on Apple.

Read for yourself on:
http://tech.fortune.cnn.com/2011/03/03/steve-jobs-reality-distortion-takes-its-toll-on-truth/

Monitoring and securing REST Services on the Vordel demo image

2011-03-06T14:36:00.000Z

Vordel provides a demo "sandbox" Virtual Machine everything you need to familiarize yourself with the Vordel products, including sample Web Services which you can apply policies to. The demo VM can be opened in Oracle VirtualBox or in VMware Player or Workstation.

The sample "StockQuote" service on the Sandbox image has HTTP GET interface, as well as the SOAP 1.1 and SOAP 1.2 interface. This makes it useful for REST/SOAP protocol conversion scenarios.

First, make sure the demo services are running (double-click on the shortcut for the sample Web Services on the demo image's desktop). Then if you point browser to this URL on the sandbox, you'll see the stock quote for the ticker "VRDL":

http://webservices:8000/axis2/services/StockQuoteService/getPrice?symbol=VRDL

[ Note that "webservices" is mapped to the local loopback address using the hosts file. So you could use "localhost" instead of "webservices" in the URL if you like].

There is also an "update" method on this same Web Service, also called with a REST interface. This is for updating the stock price. Calling the following with a GET from a browser will result in some stock price manipulation:

http://webservices:8000/axis2/services/StockQuoteService/update?symbol=VRDL&price=84.0

Now once again call getPrice for VRDL, and see what happens. The stock price has doubled.

But hang on: One of the principle of REST is that a GET should not have "side effects" (and updating a stock price is clearly is a side effect). Also, pure REST shouldn't involve the use of HTTP QueryString parameters like we just used, even though that is how the majority of people understand REST is used (in pure REST the parameters are contained in the URL itself, not "after the question mark").

So let's use the Vordel Gateway to apply some policies to these services, and make them more RESTful.

Firstly, it makes sense to only allow certain authenticated clients to change the stock price using "update", while allowing anyone to view the stock price using "getPrice". It also makes sense to force clients to use "PUT" to put up a new stock price, and not violate the principles of REST by using a "GET" for this purpose. This is a classic example of how the Vordel is used to apply different policies to different REST services. We do this by applying different authentication policies in the Vordel Gateway to "getPrice" and "update", by mapping the URIs for these REST calls to different policies at the Vordel Gateway.

In this way, we avoid the wrath of angry RESTafarians by ensuring that the "update" operation can *only* be called with a HTTP PUT (not using a GET), while still allowing "getPrice" to be called with a HTTP GET.

In addition, we want to make sure that the usage of these operations is tracked, so that we can see how many people are using "getPrice" versus "update".

How to detect if a client has accessed our REST service using a HTTP PUT verb:

The following script will detect is a client is trying to access the REST service using a HTTP PUT:

function invoke(msg)
{
if (msg.get("http.request.verb").equals("PUT"))
return true;
else
return false;
}

This script can be put in to a Scripting Language filter in the Vordel Gateway, and it will return true if the user attempted to call the service with a "PUT", but return false otherwise. This allows you to branch within a policy on the HTTP verb used, which is a classic REST use case (only certain users can do a "PUT" on a particular URL, etc).

Therefore, clients can access this REST service fine,

http://vordelgateway:8080/axis2/services/StockQuoteService/getPrice?symbol=VRDL

But if you try this next URL in a browser now, you will be blocked because you've used the wrong HTTP verb (the Vordel Gateway blocks you because you should have used "PUT"):

http://vordelgateway:8080/axis2/services/StockQuoteService/update?symbol=VRDL&price=168.0

Sending a HTTP GET with SOAPbox, SOAPui, or Poster:

Now, to use that "update" operation, you have to use a HTTP PUT. You can do this with SOAPbox (Vordel's free Web Service testing tool) or SOAPui or the simple "Poster" Firefox utility. [Note, if you're using Poster then make sure you hit "Parameter Body" so that the Content-type is "application/x-www-form-
urlencoded". Similar requirements go for SOAPbox and SOAPui. In SOAPbox, the "Request Settings" dialog, which you can see if you click on the little downward arrow beside the green "Play Button" you use to shoot requests off to a service. Click this, then drop down the appropriate HTTP Verb in the next dialog which comes up (i.e. choose GET or PUT, not the default POST).

The content you are sending with the HTTP PUT is:

symbol=VRDL&price=168.0

And note that you no longer have the parameters QueryString there (i.e. just this: http://vordelgateway:8080/axis2/services/StockQuoteService/update ). Note also that this is quite similar to Amazon's Query API (though this uses POST not PUT).

To demo this, I simply create a user called "Gordon Gecko" in the Vordel user store with password "vordel". This user is the user allowed to update the stock price. Now, when you do a PUT to the "update" operation, I mapped a policy to the URI "/axis2/services/StockQuoteService/update", so that you must authenticate as that user (with HTTP AuthN, so I dragged in a HTTP Authentication filter into my policy).

Monitoring REST usage

If you want to see the various REST methods show up in the Vordel Real-Time Monitoring, add "Set Service Name" filters to your policies so that you are flagging that the REST services show up in Real-Time Monitoring.

If you look at the Real-Time Monitoring (connect to the Gateway on port 8090 with a browser and click on "Real-Time Monitoring"), you now see how the "update" and "getPrice" services are being used. In Vordel Reporter, you can see what Gordon Gecko has been up to, since now you're authenticating the "update" operation.

Securing APIs

2011-02-28T08:03:00.000Z

One of the key questions which comes up in API Management is about which authentication scheme to use. Gunnar Peterson has written, in a different context, about the benefit to the security architect of providing a menu of authentication schemes to use. Some clients are limited by what authentication scheme they can handle, and by providing a "menu" of authentication schemes at the API Gateway level, this can be handled. Within a policy (expressed as a "circuit" in the Vordel Gateway) you can handle clients differently depending on how they authenticated.

So which API authentication schemes are on the "menu"? Of course there is HTTP Digest Auth and mutual SSL. But there are specific API authentication schemes similar to Amazon's Query API authentication. If you want to learn more about this API authentication option, then on the Vordel website there is a video example showing API authentication for iPhone apps and Facebook as clients. If you push the video on to the 20 minute mark, and listen for a few minutes, you can learn about how the Vordel Gateway provides the API security, making use of HMAC digests with SHA1. If you're familiar with the Amazon Web Services Query authentication, you will recognize this:

So the options for API authentication balance flexibility (providing customers with a menu of authentication options) and security (policies which vary access depending on which scheme the client uses). A Gateway provides this balance, versus hardcoding the scheme into the API itself.

Replacing walls and PDFs with conversation and videos

2011-02-23T15:01:00.000Z

James Governor from Redmonk has a piece yesterday about how companies often don't "get it" that people do not want to register for PDFs, or even deal with PDFs in the first place. He says that "Text is the language of the Net. It’s the language of blogs". I agree, but I would add that video is also a key language of the Net. Want to see how the Vordel Gateway works with Oracle Entitlements Server? Here's a video on YouTube showing it. And here is a blog post by my colleague Josh about the Vordel / Oracle Entitlements Server interop. Text and video. All Google searchable. And no registration wall.

To echo one of the comments on James' piece, that mobile is driving this, I'd add that it is mobile which is driving video as well as text. My Droid 2 plays YouTube videos just fine, enabling people to view a Vordel Gateway demo video right on their phone. You would be amazed how many people I talk to who say "Yeah I have watched the video" when I mention a particular Vordel feature (e.g. our Security Token Service support).

Take for example this video (no registration needed) of a Vordel customer (Blackhawk Network) explaining how they use the Vordel Gateway to manage a REST API consumed by Facebook Marketplace and iPhone apps. I'd argue that viewing the video, listening to an enterprise architect explaining exactly why they architected the solution like they did, and why they chose Vordel, is certainly more valuable than PDF and in fact it compliments text-based blogs well.

This is the Cluetrain idea: Markets as conversations. Get information out there, include customers and partners in the conversation, and don't hide information behind PDFs and registration walls. Engage with text in blogs, certainly, but also using video which is just as much a first-class citizen of the Internet.

Covering your *aaS - A security checklist for cloud models

2011-02-16T17:14:00.000Z

If you ask three organizations how they are using the Cloud, you will get (at least) three answers. One may be considering using Google Apps for email, to avoid asking an admin to reboot mail servers at 4am to clear an email backlog. Another may be considering using Terramark or Amazon EC2 to spin up compute power to run processor-intensive work (like DNA sequencing, let's say). Another may be considering using Amazon's S3 as external storage. Here is where the *aaS model comes to the rescue. Cloud usage fits relatively neatly into the different categorizations of SaaS, PaaS, and IaaS.

Using this categorization, I recently wrote a cloud security introduction for CSO Magazine which uses these categories: SaaS, PaaS, and IaaS, to show how security applies differently in each case. Check it out...

Cloud Security Alliance piece - Single Sign-On to Cloud services

2011-02-11T13:57:00.000Z

I wrote this piece recently for the Cloud Security Alliance for Infosecurity Magazine on Single Sign-On to the Cloud. As a practitioner in this area, it is striking how service providers such as Google Apps enable access to their service (corporate Gmail inboxes, Google Docs) via API keys. In the case of Google Apps, the key is used to sign a SAML 2.0 assertion sent up to log the user into their email inbox.

I'm sometimes asked for Cloud security predictions. One prediction I have is that it is only a matter of time when API keys are stolen from an organization, and used to access resources such as email inboxes and sales leads. CSOs are mostly not aware that these keys, often sitting on hard drives or baked into apps, are vital to protect. In the article I talk about the API key protection options. Check it out...

The unexpected link between procreation and password recovery

2011-01-27T14:19:00.000Z

Let me first say that the interface to FedEx Print Online is a pleasure to use. It did exactly what I wanted me to do, allowed me to view my document as it would look printed, compare shipping options, and then track my order easily.

However, when I registered, I noticed that one of their "password recovery" questions is "What is the middle name of your youngest child?". So what is the problem with this question (apart from the fact that it's publicly available information, often on Facebook, not to mention City Hall)? The problem is that if you have more kids, then the correct answer changes. So you would have to think "OK, what was the middle name of my youngest child at the time when I registered with Fedex Print Online". In fact, having more kids can have the unexpected knock-on effect of locking you out of FedEx Print Online. Maybe they should have a caveat there: "Note: Please take steps to ensure you do not have more children, if choosing this password recovery question for FedEx Print Online".

Tracing Cloud Computing back to 1959

2011-01-25T18:09:00.000Z

This paper on Cloud Computing by CA provides some good solid descriptions of the role of a Cloud Gateway "for IT management facets such as Service Management, Data Center Automation, Application Performance Management, Security Management, and Infrastructure Management to extend the traditional IT management stack". It is a good approach to providing an infrastructural approach to managing usage of Cloud-based services, rather than baking this management into the applications themselves. Overlaying management infrastructure on top of application is, of course, a key aspect of what CA does, so it's not a surprise that this is where they see added value.

The same paper also includes this history of Cloud Computing, which takes the "timesharing" analogy. [ Note, an alternative approach is to see Cloud Computing as an extension of outsourcing, or to see it in terms of object re-use. As with all successful IT trends, like success in general, it has "many fathers"].

A Brief History of Cloud Computing

Despite its new-found prominence today,
cloud computing is not a new concept. In
fact, its roots can be traced back to the
early sixties. In January 1959, John Mc-
Carthy predicted that advances in timesharing
technology would lead to an
ultimate direction in computing, where
computing power would be sold as a utility
similar to water or electricity. This idea
was summarized in memorandum he sent
to MIT Professor P. M. Morse on January
1, 1959:
“This memorandum is based on the assumption
that MIT will be given a transistorized
IBM 709 about July 1960. I want
to propose an operating system for it that
will substantially reduce the time required
to get a problem solved on the machine....
The proposal requires a complete
revision in the way the machine is used....I
think the proposal points to the way all
computers will be operated in the future,
and we have a chance to pioneer a big
step forward in the way computers are
used....” *
In 1961, to mark its centennial anniversary,
MIT (Massachusetts Institute of
Technology) organized a series of lectures
on the future of computing. In one of the
lectures Morse publically voiced his idea.
However, his idea never really developed
given the technology constraints at that
time.
With the Internet offering a significant
bandwidth in the nineties, the cloud computing
concept started making the rounds
again. With the introduction of Salesforce.
com in 1999, it finally arrived with
full thrust. The next big step was Amazon
Web Services in 2002. In 2006, Amazon
launched its Elastic Compute Cloud aka
EC2 as a commercial service, offering
computers on rent. This was the first
widely used cloud computing service. And
since then the world has never been the
same again... cloud computing had finally
arrived!
http://www.ca.com/Files/TechnicalDocuments/ca-technology-exchange_233637.pdf

Also in the same paper has a useful taxonomy of actors in the Cloud infrastructure area:

...based on the Service type, cloud services can be classified into
the following areas:
Cloud Service Provider (CSP):
Organizations that offer the services
(computing services, application services, etc.) for consumption through
a well-defined set of interfaces based on an agreed cost model (for example,
Amazon EC2).
Cloud Service Consumer (CSC):
Consumers that use computing services
provided by a CSP through a well-defined set of interfaces. For example,
cloud services provided by CA Clarity PPM On Demand could be used for
project planning and management without deploying the software inpremises.
Similarly Amazon EC2 services could be utilized by consumers
to handle peak computing load. In this case, the computing resources are
provisioned into Amazon EC2. Once the load returns to normal level these resources could be de-provisioned.
Cloud Broker/Federator:
Organizations that combine multiple trustworthy
services from different CSPs to provide a new computing service, essentially
adding value to improve on specific capabilities. For example, a
broker may combine storage services from one vendor with the identity
and access management services from another vendor to provide rolebased
storage secure storage services (for example, Vordel Cloud Service
Broker).

It's so cold that...

2011-01-24T14:59:00.000Z

With a hat-tip to Paul Madsen,

It's so cold that ... OAuth tweets are falling out of the sky
It's so cold that ... API keys could get stuck in locks
It's so cold that ... Conditional Routing paths must be shoveled out

(Those temperatures are Fahrenheit, by the way)

Looking back at 2010

2011-01-21T20:28:00.000Z

From CloudComputingArchitect.com, Vordel highlights of 2010:

Key Highlights of Full Year 2010

* Year over year growth of 82%
* Profit figures ahead of target for FY2010
* Released Vordel 6: re-architected for ease of use and performance
* 30 new customers added in 32 countries.
* Expanding management team includes Ed Jackowiak joining as VP Sales, North America
* New offices opened in Boston, Paris and Düsseldorf
* Webinar series on New Architectures for SOA and Cloud Application launched with ground-breaking Blackhawk/Safeway case study for Facebook Marketplace
* Vordel Cloud Service Broker technical first integration with VMware vCloud Director
* Launched inaugural Vordel User Group meetings in EMEA

Chess Analogy Redux

2011-01-20T12:48:00.000Z

Chess is currently top-of-mind chez O'Neill due to my son teaching himself chess by playing gnuchess on xboard on a Puppy Linux box I put together based on an old PC abandoned on the street by a neighbor who skipped the state during the height of the foreclosure crisis. We now play with an actual wooden chess set and have books such as "How to beat your dad at chess" (which, as my son pointed out, was not supposed to be for me to read cover-to-cover, thus defeating the purpose). One thing we've been working on is the chess opening. As an infosec person, it's hard to do anything (take a flight, start a car) without thinking of the infosec analogies. And chess openings are no exception. But Gunnar Peterson is way ahead of me on the infosec/chess analogies...

Last January, I quoted Gunnar Peterson used who a chess analogy for AAA, as part of a larger post:

I think of AAA access control technologies as Opening Game strategies - many people think of Kerberos and other ticketing systems are security, but really they just establish the initial ruleset for operations, the real game begins once they're in place, in use, and under attack. The structure used at the opening does not dictate all or maybe even most of the events that occur in the middle and end game.
http://1raindrop.typepad.com/1_raindrop/2010/01/beyond-the-opening-a-priori-is-a-problem.html

This made me think about AAA in particular, and how it breaks down into its component parts. So much effort is put into the first "A" of it, i.e. to authentication. But much less effort is put into the next steps. Authorization in particular is often murky. Even when you look at how people use Web Access Control products which do authorization, you often find that they are only being used for authentication and their single sign-on feature. I've referenced this chess analogy during 2010 in screencasts and webinars focusing on actual authorization products, including this screencast on Vordel's interop with Oracle Entitlements Server (Vordel as PEP and OES as PDP) and this webinar with Axiomatics. Authorization is "what happens after the opening" and deserves more attention than it's got in the past. The chess analogy is a good way to explain this, since it's not a case of "Make the opening then hope for the best". The opening is important, sure, but there is also the middle game and the endgame.

So, now, a year later and another nice chess analogy from Gunnar. He talks about where a Gateway fits in front of the ESB, saying:

"If you front end the ESB (Or other aggregator) out to the Mobile clients, you are not simply publishing the data and Web services to the Mobile world, you are publishing you entire Enterprise Attack Surface as well. Think about what is exposed if the Gateway is not there to mediate.
So Gateways are quite important because they can play a role across the entire Attack Surface, including

Communication channel: proxy network protocols
Method: access control, publish only authorized methods
Data: content validation, encryption, and integrity services
http://1raindrop.typepad.com/1_raindrop/2011/01/of-gateways-and-hedgehogs.html

So where does chess fit into this?

If you push all these defenses back into your app not only do you have the Attack Surface-bloat problem, you also have the issue of affecting performance and performing the security checks in the same space as that which you are trying to defend. In other words by the time you spot the attack it may already be checkmate.

i.e. if you don't have a Gateway in the architecture, then you're losing out on your well-defined opening, and it's the equivalent of jumping straight into the middle game without a clear opening strategy. This is another nice chess analogy which I'll be using in 2011 - thanks again Gunnar :-)

The usual caveats of infosec analogies apply, as well put by Chris Hoff here.

In Paris in the spring-time : Free SOA Architecture Workshops

2011-01-19T12:45:00.000Z

Paris in the spring-time brings up images of sipping coffee while tearing open a freshly-baked baguette, and admiring the city. So why not combine it with a free SOA Workshop on Security, Performance and Governance for SOA Architectures. My colleague Philippe Leothaud, who recently joined Vordel from Bee-ware, is leading a series of complimentary hands-on, case-study led workshops in Paris next month.

More information here en français:

Description:
http://www.vordel.com/news/press/11_01_11.html

Registration:
http://www.vordel.com/news/events/03-02-2011-Paris.html

ScaleXtreme

2011-01-18T18:58:00.000Z

There are a couple of reasons to keep an eye on ScaleXtreme, who received venture capital from Accel Partners this week.

Firstly, they are focusing on the area of data center server management which has been disrupted due to the fact that organizations are making increasing use of virtual servers hosted by Cloud-based providers such as Amazon and Terremark. Case in point: One of Vordel's customers in the pharmaceuticals area routinely spins up hundreds of servers on Terremark to process clinic trial data, then spins them down again, benefiting from Vordel's VCloud API support. To be able to manage those Terremark-hosted servers alongside on-premises servers is a valuable thing.

Secondly, one of the founders of ScaleExtreme is Nand Mulchandani, who was a co-founder of Oblix. Oblix was a Web Access Management vendor whose main product competed with SiteMinder and Tivoli Access Manager, amongst others. Oblix came relatively late to the game of Web Access Management but brought some key differences. One which stood out for me was its Microsoft interop. I did some Oblix deployments myself, and found it to be a well-designed product, so it wasn't really a surprise when it was bought by Oracle to become Oracle Access Manager ( I recently recorded a screencast video of the Vordel Gateway operating with Oracle Access Manager).

An interesting architectural aspect of ScaleXtreme is how it gets around the "How can I manage my internal servers via a Cloud-based service through mobile devices, when they are behind the firewall?" problem. The way it does this is by using agents which are installed on the internal servers. These then are used to communicate with the Cloud-based service. The Cloud-based service is therefore the main part of the architecture. This justifies the observation by Nand Mulchandani that the Cloud component of ScaleXtreme is intrinsic, not some kind of bolt-on.

Definitely one to watch...

Drag-and-drop productivity tips in Vordel Policy Studio

2011-01-13T11:39:00.000Z

Did you know if you can drag and drop a filter onto an existing filter in Vordel Policy Studio, and Policy Studio will automatically create the path from the existing filter to the new filter? You can see this in action in the short screencast video below:

You may have noticed another productivity trip in the video above, whereby you can type in search text in order to narrow down the list of filters to drag-and-drop.

Here's another neat productivity tip: If you drag and drop the new filter onto a filter which already has a green "success path", then Policy Studio will create a new red path, as shown in the screencast video below.

One step forward, one step back

2011-01-11T08:43:00.000Z

Chris Swan has a good post this week about how the compliance footers added to email messages by Google's Postini actually invalidate the DKIM signatures created by Google Apps. Changing a message will do that to a signature, of course, but it is disappointing to see a model where where layering on more security (the compliance header) actually cancels out an existing layer of security (the signature).

[ Incidentally, the post contains a reference to bacn, a very useful word which I didn't know existed... ]

SAML, SSO, and Web Services at the forefront for 2011

2011-01-04T14:36:00.000Z

Roger Grimes has a piece in Infoworld today on security trends for 2011. Two which I would pick out are (a) Token protection, and (b) the Death of the DMZ.

Follow the token to find the key

He points out that:

Users will want full-range access through one logon name and password/logon token.

As such, you will be asked to make that happen, even between systems you don't control. You'll do this by using Web-based federation standards, cloud gateways, and claims-based identity metasystems. Instead of being worried about authentication protocols and password hashes, you'll be protecting XML-based SAML (Security Assertion Markup Language) tokens.
http://www.infoworld.com/d/security-central/five-security-trends-2011-and-beyond-434?page=0,1

To put this into practical context, consider how one of Vordel's US education-sector customers is using Vordel for single sign-on of college students into Gmail (and Google Apps in general). It is SAML which is used to log the users into Gmail. Roger Grimes points out that the SAML tokens must be secured, which is very true (Google requires them to be signed, that is part of the protocol). But notice the set of keys in the diagram below. Those are the API Keys. If you follow the chain of trust, those are what really needs to be protected. With those keys, a malicious attacker could construct their own signed SAML token which would log them into someone's Gmail account. So it is absolutely vital that those API keys are protected. My own prediction for 2011 is that the sensitivity of API Keys will start to be realized, and organizations will realize that their Gateway/Broker solutions must protect those keys at all costs. After all, the API keys are linked to pay-as-you-use Cloud services, and to sensitive information (like email, sales leads, or shared documents).

DMZ RIP

The second point I'd echo is how Roger Grimes foretells "The Death of the DMZ". Another way to express this, by Bill Mann of CA, is that "We are all on a public network". The solution is not to think about perimeters, but to think about the data. Shrink the perimeter right down to the data itself. Again, Web Services technologies apply here. If (as Roger Grimes recommends in his first point in that article - "What isn't Web will become Web"), you are using Web technologies, then that allows you to make use of WS-Security and XML Encryption in order to selectively encrypt the sensitive data, even within a message itself. Again, Gateways and Brokers are what does this. The problem to overcome is the performance cost of all that cryptography and message processing, which is why XML Gateway products are optimized for performance.

It's going to be an interesting 2011!

Welcome onboard @xmlgatewayguru

2011-01-04T04:35:00.000Z

I'm very pleased to say that Josh Bregman has joined the Vordel team here in Boston, and has hit the ground running by blogging at http://xmlgateway.blogspot.com.

Over the years I've known Josh, I've found that he's an excellent source of security know-how, product configuration tips, and, last but not least, Red Sox tickets :-)

You can also follow Josh on Twitter at: @xmlgatewayguru