The controversial “Open Cloud Manifesto” is intended to ensure users of Web-based applications such as those offered by Salesforce.com, IBM and Microsoft have the ability to port their data to new providers should they choose to switch services. However, the limitation of cloud services is the lack of secure inter-cloud communications and data exchange between hosted applications.

The availability of ubiquitous and reliable high-speed connectivity has created a boom in software-as-a-service and Web-based applications. According to Gartner, SAAS will be a $53 billion market in 2009 and will grow to more than $150 billion in annual sales by 2013.

With that kind of growth, IBM and Cisco Systems this week unveiled the Open Cloud Manifesto, a pledge among leading vendors supplying cloud-based services to maintain open standards to give customers the ability to exercise choice in selecting and changing services. Part of the concern behind the manifesto is to ensure that no one service provider monopolizes the market or unfairly locks customers into one cloud.

"It's not that everything is going to be perfectly compatible, but it is going to be somewhat similar so that you can move from one vendor to another. It gives businesses the comfort level they need to buy," said Stephen O'Grady, an analyst with technology research firm RedMonk told Reuters news service.

Some vendors—most notably Microsoft—have criticized the manifesto as being a ploy for trying to shape the SAAS marketplace. However, some say the real inhibiter to widespread SAAS adoption and unlocking its value to business-technology users is some form of secure exchange of data between cloud-based applications and services—a form of federated identity management for the Web services.

“This isn’t a new problem; it’s a reflection of a level of maturity,” says Nick Nikols, vice president of product management for identity and security at Novell. “Identity provides the right context for a lot of these problems. You can have flexibility of providing access without some context of identity.”

Recently, electronic privacy and security public interest groups raised concerns to federal regulators about the security of data stored by Web services providers. Some even called for investigations into the security of data stored by Google’s Doc services and Amazon’s S3 storage service. Secure access to cloud-based information and data is relatively straight forward, with users granted accounts and provisioned access rights and privileges based on their account settings. Levels of authentication can vary based on the security requirements of the contracting companies and sophistication of the service provider. Today, many SAAS and Web services are protected by common password access control mechanisms and SSL encrypted connections.

Users can have multiple instances of various hosted and Web-services open on their desktops, authenticating to each of them for access or creating a simulated single sign-on through a locally administered password vault. Most applications will enable cutting-and-pasting of information between applications. However, there’s few ways that these applications can automatically port information seamlessly and transparently between them, especially across multiple domains. For instance, Salesforce.com’s CRM application today cannot easily share information with a Web-based Oracle database or SAP finance application.

In years past, security evangelists thought public key infrastructure (PKI) would provide the means for sharing information across disparate domains. The federal government spent millions of dollars building a PKI bridge so federal agencies—each operating their own domain—could digitally share information and documents. The Food and Drug Administration did successfully implement a PKI infrastructure to expedite data submissions by drug companies for market approvals. But few enterprise-level PKI implementations achieved a measurable level of success.

Federal identity management may hold a model for opening Web-services to application-to-application data exchange. In a federated identity management scheme, two domains agree to trust the credentials past between each based on a relationship established out-of-band. Federated identity management often works well in theory, but the logistics and audit trails get murky when a third domain with no relation to one of the original parties is introduced to the scenario.

The answer to the cloud computing identity management conundrum may just be putting identity management in the cloud, too, says JG Chirapurath, director of identity management and security marketing at Microsoft’s identity and security unit. He believes having some or all identity management as a cloud-based services that’s kept in synch with the on-premise user activity may provide the means for cross-domain data exchange between cloud applications.

“It comes back to a matter of trust. SharePoint trusts me under a certain set of conditions, but how do you get SharePoint to trust Siebel?” Chirapurath says. “Across boundaries, you can share information in a fairly fine grained way that’s based on identity, so you need a flexible scheme of identity; an identity you use at work and that will go with you to use in different places.”

Cloud-based identity management could be a big business opportunity for solution providers, since most identity management platforms are designed for large enterprise environments with 5,000 or more employees. By pushing identity management into the cloud, solution providers could deliver and manage identity services for small and midsized companies.

“It’s a tremendous opportunity for solution providers and partners, as rich as the on-premise world,” says Chirapurath. “It’s an amazing opportunity for partners because you can’t do this level of implementation without partners.”

Major providers of SAAS applications and hosted services—including Microsoft, Google and Amazon—did not sign the Open Cloud Manifesto but are participating in talks for its further development. For now, the manifesto is focused on ensuring data and service migration, not necessarily real-time, cross-domain data sharing.