Love it or hate it, Microsoft is the de facto standard in corporate Identity. In truth, I think this is well deserved. Despite spotty support for standards, Microsoft's suite of products -- including Certificate Server, SCCM, the flagship Active Directory, and Active Directory Federation Services in combination with the core Windows login -- has long been the corporate identity standard.
As businesses move to the cloud, this situation will change. If you don't want to manage your own application servers, operating systems, and hardware and instead opt for the cloud, why would you want to manage an infrastructure for identity? This leaves us searching for the identity solution to what I call the "all-in" cloud architecture.
[ Also on InfoWorld: The all-in cloud architecture of tomorrow. | Learn how to work smarter, not harder with InfoWorld's roundup of the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
I hate to use the word "security" when talking about identity. But I often have to because it refers to a set of concepts that people understand. When I say "identity," I'm talking about the parts of security that are authentication and authorization -- who are you and what do you want? -- and how we provision that identity as a data construct.
XaaS identity scenarios
In the marketing avalanche of as-a-service acronyms (hereafter collectively referred to as XaaS), you'll find the emerging field of IDaaS, or identity as a service. The idea is that you can manage user identities with a Web application the way you'd manage prospects and sales in a CRM app.
But identity in the cloud is more than that. Let's say you created a user and declared her a salesperson with management responsibility. She might use Salesforce.com for CRM, Google Apps for email and documents, and a custom application deployed on a PaaS such as Cloud Foundry. That PaaS app might even call services on Salesforce and Google Apps.
In general, your IDaaS will use the SAML protocol to handle authentication and authorization to your various XaaSes. In some cases, the user may authenticate to the IDaaS and authorize on the XaaSes with the Oauth protocol. But what exactly is this IDaaS thing?
Should you stick with what you know?
One possibility is Microsoft's IDaaS. According to John Shewchuk, a Technical Fellow at Microsoft, "You can think of Windows Azure Active Directory as essentially Active Directory running in the cloud -- a multi-tenanted service with Internet scale, high availability, and integrated disaster recovery."
Microsoft's strategy supports both on- and off-premise Active Directory as well as hybrids between the two strategies. According to Shewchuk, the Azure Active Directory "is an open directory that can be used by any third-party application or service, and it supports industry standard protocols such SAML, OAuth 2, and OData."
Or should you go with something cloudier?
There are other possibilities, such as PingOne by Ping Identity. Patrick Harding, CTO of Ping Identity, notes that "the cloud in 2012 is different from the on-premise world of 2002. Back then a proliferation of different directories emerged that were then subsumed by AD [Active Directory]. Most on-premise apps were tied to AD for authentication and role/group management."