OpenID/OAuth – a step forward in the Interoperability field

As Reuven reported in the CloudForum Google Group, Google has released its OpenID/OAuth  implementation. This is a major step forward in the Interoperability field. This example is fundamental to show how it’s possible to add real “conversation” capabilities (or information exchange) among Cloud Computing Service providers.

As I’ve already said, instead of developing new tools or platforms, reusing old ones and trying to combine them is, in my perspective, the only way to achieve real Interoperability in the Cloud. Cloud Computing is something that must be a reality now, we must not be forced to wait for future or complex interoperability platforms.

The work that Google has released is very important and it will allow, for instance, that a user from Zoho Writer can use data from a Google Docs Spreadsheet and then make the result available in his Linkedin profile. This is a theoretical example, but it’s intended to demonstrate the power of these new tools.

In other perspective, with OpenID/OAuth (and also maybe using I-Card/Higgins) we’ll be able to deploy Identity Management platforms (authentication and authorization) in a federated way, but without the need to use closed solutions. These federated platforms are very common in academic institutions. Even though these federated IdP are usually built with open technologies, like the OASIS SAML specifications and Internet2 Shibboleth software, they lack real Interoperability capabilities. They have very inflexible IdP discovery mechanisms, and users’ attributes or users’ data sharing mechanisms. Despite all the excellent work that is continuously done by Shibboleth, and even with the recent introduction of SAML2.0, these problems are still unsolved. Using the OpenID/OAuth approach, the federated IdP will definitely obtain major benefits.

[updade 23/07/09]

This short post  has been discussed in the projectconcordia mailing list: (http://lists.projectconcordia.org/pipermail/community/2009-July/002007.html), and I think I should clarify some of my initial thoughts. First, this is not a “OpenID Vs SAML” text. I’ve worked with both in the past and I’m continuing develop this work in an integrated way. I’m responsible to manage and develop an SSO platform initially  designed to support  SAML  2.0, and I’m now updating this platform in order to support OpenID as well.

Another short note, when I was talking on  SAML 2.0 being only recently introduced, I was talking on the context of the Shibboleth stable versions.

Cloud it or not to Cloud it – Interoperability

This thing called Interoperability in another characteristic of the Cloud that must be studied and developed (promoted) with all the attention and care. We must always retain in our thoughts that Interoperability is something very hard to achieve. Our IT history is full of examples: we cannot forget the work needed on simple things like office applications formats and how long we had to wait until we had an open format (ok, now we have two Open Document Formats).

Reuven Cohen on a recent blog post presented very interesting ideas and intentions about this subject. He also had given a name to his efforts: “Unified Cloud Interface”. The UCI specification is, in Reuven Cohen’s intentions, to be implemented as an extension to the Extensible Messaging and Presence Protocol (XMPP). Which is a great decision, reinventing everything every time is usually a very bad decision, and  it also goes against the very definition of Interoperability.

Having a UCI will be major step forward in the matter of Interoperability, but it will only work if we also provide a method to control access and if we base it all in a strong Identity Platform. For authorization we already have OAuth or even a more generic specification like XACML, for Identity management we also have OpenID, and SAML for federated (closed) solutions. Finally we already have the UDDI (Universal Description, Discovery and Integration), which aims to provide an Internet application a way to communicate and interact over the Internet.

In the real world we already have good examples of Interoperability efforts,  besides the ones  in the Identity management field, which I’ve talked about in a previous post,  we have also the work done with OAuth by Google or the one done by Yahoo.

Cloud it or not to Cloud it – Identity Management

Everything in our society, from business to the Internet, is about trust and reputation. A solid Identity Management Infrastructure is fundamental to “transmit” reputation, and then, to be able to create the trust links.
Preparing a migration to the cloud must always be preceded by the creation of an Identity Management platform. With it, you will be able to interact with the cloud service providers, and also integrate your local infrastructure with the cloud: users will be able to access your LAN using a 802.1x access control system; login in a desktop with Microsoft Windows Cardspace; read their email on the Google APPs; do a deal with a Salesforce CRM application; write a document on ThinkFree.com Write (or better, on the Zoho Writer), etc.

Ok, this is not as easy at it looks (at least for the time being). Identity Management is a very complex subject and a target of many and very enthusiastic discussions. As an example we have the recent “fight” about the OASIS XRI 2.0 specification. Even the “father” (Tim Berners-Lee) of the Web was part of this discussion:
“We are not satisfied that XRIs provide functionality not
readily available from http: URIs. Accordingly the TAG recommends
against taking the XRI specifications forward, or supporting the use of
XRIs as identifiers in other specifications”

You can follow this on the openid.net post: http://openid.net/pipermail/general/2008-May/004817.html.

Despite all of this, we already have a group of technological solutions that provides the necessary basis for a solid Identity Management infrastructure. The last one to joint this group was the Geneva from Microsoft, but already have solutions from the major IT companies:

The majority of this solutions are following the path of normalization, they are implementing OASIS specifications like WS-* (WS-Trust, WS-Secutity, etc),  SAML1/2, or even OpenID.  This is a very important decision, without this normalizations efforts we won’t be able to achieve one of the major objectives (characteristic) of a real Cloud – Interoperability. A great example in this direction are the recent Microsoft decisions about Geneva: http://www.identityblog.com/?p=1018.

Another example, this time in the OpenID field, is the work done by the OpenID Japan. Take a look on the incredible list of member companies that they have, including technological companies, banks and insurance companies.