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 28, 2010
Monday, June 14, 2010
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
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
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: http://vordel.com/products/vx_gateway/
Wednesday, June 9, 2010
"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
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.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".
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.http://arstechnica.com/business/news/2010/05/investing-in-the-cloud-not-revolution-but-evolution.ars
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
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 firstname.lastname@example.org . Happy SAMLing! :-)