The recent announcement from an official MSFT blog that Windows 8 will allow sign-in to the machine with a Windows Live ID marks the final ascendancy of cloud identity systems. Until recently, there were two principal notions of identity recognized by Windows.
- Local accounts, maintained by that PC and recognized by no other machine. This is what a consumer might have on their machine at home: if there are 5 people in the household, each one gets a different account . Note that passwords are not required; the accounts can be setup such that merely clicking on the user tile is enough. In this model accounts are used purely for customization: each person can pick a different background, shortcuts, have different applications start up when they login, their web browser remembers their unique history, etc. The identity can not be asserted anywhere else: in order to read email for example, the user has to type a different password to sign-in to their mail provider. (There is a subtlety here in that this password for Hotmail/GMail/Yahoo etc. can be cached, making the local Windows account act as a “key ring” or “credential store” for other cloud identities, but the Windows identity itself is not recognized in the cloud.)
- Domain accounts: This is the enterprise scenario, where an IT department sets up an Active Directory system for central management of all computers in the company. Identities are then issued by the centralized system and recognized at by all machines that are members of the AD domain. The user types in a username/password to logon to their laptop; this part of the experience is not changed. But the protocol used under the hood ensures that the same identity authenticated by those credentials is also good for accessing resources on a file share, sending a print job to the expensive color printer or downloading email from the local Exchange server the IT department runs.
Enterprise identity systems were the first to confront the challenge of integrating with the cloud. As basic functionality such as email, CRM, content management etc. were increasingly outsourced to web providers in the name of efficiency, some solution became mandatory to allow use of existing enterprise identity to authenticate to the cloud. Asking users to manage different passwords for each outsourced service quickly makes IT departments very unpopular– not that they have any political capital to burn, for the most part. Typically this is achieved by using a “bridging” solution that converts the brand of identity expression used in the enterprise eg crusty-old Kerberos, into a different format that is more in-tune with the fashionable standards on the web, which means typically angle-brackets and XML eg SAML.
While several companies market such bridging solutions for the enterprise market, until now the most sophisticated form of integration available to home users remained the old-school password manager: the local device will store all your passwords for websites, much like a keyring, the story goes, and once you login to that device you can use any key to unlock other doors out there. Variations on this theme, such as cloud-based password managers that allow roaming the keyring between different machines, remained the state of the art for PC and Mac platform.
In a sense this was understandable: being an open ecosystem, the PC had to cope with a myriad of different authentication systems, proprietary schemes vying to become standards (mostly dead-ends it turned out) and incompatible usage models across the board: from the security conscious paranoid user to the convenience-driven casual web surfer. Instead most of the innovation in simplifying the identity experience happened on relatively closed-platforms, what Jonathan Zittrain might have termed “appliances” with less-stringent requirements for integration beyond the services provided by the platform owner: iPhone, Android and ChromeOS proved how easy it is to use cloud identity when there is exactly one identity provider.