Monday, June 28, 2010

Role-based attitudes to the Cloud

Vanessa Alvarez in InformationWeek's "Plug into the Cloud" points out something I've noticed also. IT departments are often unaware of who in their own organization is using public Cloud services. Those with a role in IT are not aware of how line-of-business managers are using public Cloud services (or even if they are using them at all). As well as the obvious security issues with this, it also points to a lack of governance. One less of SOA Governance which applies here is that service usage must be discovered first, then brought under an umbrella of policy. Unless this first discovery stage is met, services are never brought under control. This is one of the roles of the Cloud Service Broker - to discover the public Cloud service usage and bring it under the same control as internal service usage.
Changing CIO & IT Roles

Many panelists pointed out that the disconnect between IT and line-of-business (LOB) managers continues to be challenging. IT is really not aware of who is using public cloud services and therefore, doesn't really see the need for deploying a cloud computing model that will deliver the features and functionalities that LOB managers are turning to the public cloud for.

Monday, June 14, 2010

At Gartner Summit: How Cloud Service Brokers enable the move beyond IaaS

Today at the Gartner SOA & Application Development and Integration Summit here in London, Benoit Lheureux made the case for how the Cloud Service Broker enables brokerages to make the step beyond Integration-as-a-Service (a term he originally coined).

Benoit has a blog post which provided a taste of his talk today, in which he lays out the case for why the CSB model will marry governance to IaaS providers. In the actual talk, he elaborated on what is just hinted in his blog post. For example, he explained how the social aspect would allow consumers of IaaS services to potentially make their own changes to services, such as changing their interface from FTPS to Web Services. He also explained that the EDI Value-Added Networks (my own background - I worked for a VAN 12 years ago) will continue to operate, but the move to a Cloud-based model will be accelerated by the enabling technology of the Cloud Service Broker.

On a personal note, Benoit also talked about how this is his first business trip after his twins were born, and the emotion in his voice reminded me of the first trips I made (also to London) when my two kids were born.

Friday, June 11, 2010

SOAPbox - Testing Cloud and SOA services beyond Windows

In reply to @jaapgorjup: Does SOAPbox support platforms other than Windows?

Of course :-) The support matrix is up under the "Specifications" tab on the SOAPbox download page.

I run SOAPbox on Ubuntu Linux - here is a screenshot of SOAPbox on Ubuntu sending a message to the Vordel XML Gateway running the same XML-to-JSON conversion I referenced in yesterday's blog post.

Thursday, June 10, 2010

How to convert XML to JSON

JSON is a very popular choice for transmitting data on the wire, especially since it is widely used for Apple iPhone app development. The usage of JSON allows a developer to skip the step in the browser where incoming XML must be parsed and read into an object. Instead, a serialized JavaScript object is sent, often including the data it needs already. So, no need for XML. But, in order to create this JSON structure in the first place, it is a good idea to offload this task onto an appliance such as an XML Gateway. The XML Gateway then serves up the JSON (to an iPhone for example), dynamically converting it from the source XML.

Here you can see XML being converted dynamically to JSON by an XML Gateway, as tested using the free SOAPbox tool:

This is enabled at the Gateway side by a relatively simple circuit. One key gotcha to remember is that when serving up JSON, make sure the content type is set to "application/json". Otherwise, clients may choke on it since they will not realize what it is.

Grab a copy of the Vordel Gateway to test this XML-to-JSON functionality here:

Wednesday, June 9, 2010

At the European e-Identity Management Conference in London

This week I am at the European e-Identity Management Conference in London. This afternoon I am speaking about identity mediation to the cloud. I'm focusing on the role of a Cloud Service Broker, using a Security Token Service for conversion between identity token types. There is a tendency to focus on the newer token types (OAuth, OpenID) but the biggest requirement is often to support the more established (and often proprietary) identity token types such as the CA SiteMinder smsession token. Mediating these to the Cloud, enabling single sign-on to the Cloud is the great value of a Cloud Service Broker working in conjunction with a Security Token Service (STS).

"Unified Field of Cloud and Enterprise"

Kim Cameron from Microsoft just gave an entertaining talk here (he joked that he is called "The Father of Identity" so often that he wonders "maybe it was something that happened when I was drunk"). Referencing David Linthicum's "Data-Integration Buzzkill for Cloud Computing" piece, he explained that you cannot consider Cloud-based systems separate from enterprise infrastructure "or indeed from other Cloud-based systems you are using from other providers", instead it is part of a "kind of unified field of cloud and enterprise". He spoke of the hybrid infrastructure of Cloud and Enterprise.

He explained that a key identity issue is that you must consider not only authentication to cloud providers (user provisioning, password synchronization) but also the larger task of managing authorization data (who is allowed to access which resource). The Authorization management problem is "exponentially larger" than the authentication problem.

To address this, he laid out an architecture which makes use of a Security Token Service (STS) to issue claims (such as "this user is aged over 21", "this user's manager is XXXX") which are then used for authorization decisions. The Security Token Service is a key piece of this "Identity Backbone for the Cloud", as laid out by Kim Cameron.

Wednesday, June 2, 2010

Single Sign-On for the Cloud

Jon Stokes from Ars Technica has an interesting interview today with Ping Li of Accel Partners - excerpt: (JS = Jon Stokes, PL = Ping Li)
JS: When you say "the new cloud stack," give me some perspective on how you've seen the evolution of the stack in the past two years.

PL: The evolution of the stack starts with the mainframe, and everyone is always trying to recreate the mainframe by taking advantage of new technologies. So client-server was taking advantage of processing technology. Web services enabled applications to be networked more efficiently. A lot of cloud innovation has been at the data layer—a lot of the interesting things have been with data processing but also with data storage and data transaction. So there's all the movement between, say, the NoSQL crowd and the new cloud-type Oracle databases. So there's been a lot of innovation in that area of the stack.

But even going up the stack, you can see people wanting to recreate the functionalities of a mainframe but in a new world. So, security: what does "cloud security" mean? A lot of interesting companies are doing stuff around single sign-on. You have 15 cloud apps, so how do you manage that in the enterprise—who gets access to what and when? We've seen cloud logging companies—these are all different services that were part of the traditional stack that are now being decomponentized and rebuilt in a cloud framework.
He hits a key question: "You have 15 cloud apps, so how do you manage that in the enterprise—who gets access to what and when?". The problem is that the different cloud apps have different authentication models, which in turn differ from the models used by older enterprise systems. So the Single-Sign On problem for the Cloud is all about alleviating the problem whereby an organization has their internal own identity silos and infrastructure such as SiteMinder and Active Directory / Kerberos, but they wish to connect to Cloud APIs. Local identity tokens such as Kerberos and SiteMinder smsession tokens are no good for fine-grained authentication to Cloud APIs which use OAuth and OpenID. What is needed is a kind of "Identity Router" which understands that "to connect to this Cloud API, we need OAuth, but in this local domain we have a SiteMinder smsession token".

The broker here is providing the "Identity Router" functionality. The dynamic mapping of identity tokens allows for messages to traverse domains, just like a network router allows packets to traverse different networks. The key value of the broker is the breadth of identity infrastructure which it supports. It is no good to support only OAuth and OpenID if you don't support older technologies such as Kerberos and SiteMinder.

Tuesday, June 1, 2010

Signing a SAML Assertion

Signing a SAML assertion in the Vordel XML Gateway is quite straightforward.

Firstly, you'll need a private key. Note that it is the private key which is used for signing. The public key (usually contained within an X.509 public key certificate) is used for the signature validation, and can be inserted into the XML Signature block, but it is the private key which is used for the actual signing. Here is a link to information about how to create a public and private key pair in Vordel SOAPbox or the Vordel Policy Studio. You can also, of course, import a private key (or a certificate and private key pair) as a PKCS#12 file. Or, in the case of the Vordel appliance with the HSM (Hardware Security Module), you can point your configuration to the private key, and the private key never leaves the hardware.

Once you have your private key available to you, you can then configure an XML Signature Generation filter (which is found in the "Integrity" group in Policy Studio). Note that it is also available under the "Design Mode" of the free SOAPbox tool, when you create a test case (under "Workspace" create a "test suite" and then create a "test case").

The XML Signature Generation filter should go after a filter which inserts a SAML Assertion. Here is a description of how to insert a SAML assertion containing attributes into a SOAP message.

Choose your signing key by clicking on the "Signing Key" button below. As you can see, it shows "(unset)" until you set it.

Under the "What to sign" tab, choose the XPath sub-tab and select the first SAML 2.0 assertion option.

In "Where to place signature", chose the option "SAML Subject (Before) (SAML 2.0)". This means that an enveloped signature is created, meaning that the signature is placed inside the SAML assertion itself. This means that if the SAML assertion is taken from the message and placed into another message, it is still valid.

When we test this with a message sent from the free SOAPbox Web Services testing tool , we see the signed SAML assertion returned. The issuer information ("Vordel") is configurable. Notice that, because the XML Signature is "enveloped", it is contained within the SAML assertion block itself.

If we scroll down the response in SOAPbox, we see the contents of the SAML assertion which we've signed. This includes details of the user ("JoeUser") who was authenticated, and the method of authentication (password).

For more information about how to configure this, contact . Happy SAMLing! :-)