There's one big problem with the growing number of cloud-based applications and platform services, and it's growing faster than its prospective solutions: They typically handle authentication for their users by themselves. And when they do enable OAuth or another method to share authentication duties between services and sites, their implementations are sometimes cumbersome, and too often users don't even notice the option.

Ideally, you should only have to log in once: when you begin your session with your PC, tablet or smartphone. The single sign-on (SSO) ideal is not just about user convenience. Implemented correctly, it could prevent a user's session from being remotely hijacked by a malicious user. Microsoft will be assembling the tools for services to enable some kind of SSO with its upcoming Windows 8. But the viability of those tools will depend not only upon, once again, how well services implement them, but also whether users will trust Facebook, Yahoo, or Microsoft itself to vouch for their identities. Today, there are a multitude of alternative architectures put forth by services opting to be your one source for identity, and ReadWriteWeb has chosen to spotlight three of them.

Radiant Logic RadiantOne

My friend and colleague David Strom introduced you to Radiant Logic last July. As you may recall, it offers what it describes as "identity-as-a-service," and its customers are enterprises looking to federate their employees' identity across multiple applications, both in the cloud and on-premise.

The "as-a-service" phrase is a surprising choice of words from a company that came to be known, and still is known, for providing on-premise identity management tools. How does Radiant Logic manage to provide a service it depicts as inside the firewall, from a cloud-based location that's most definitively outside?

"It's a tough thing to do, but if you look at most enterprises today, they have 80%, 90% of their infrastructure inside the firewall, on-premise," responds Dieter Schuller, the company's VP for business development. "You can't just flip a switch and move everything off-site into the cloud and still have what you have running today."

Michel Prompt, Radiant Logic's CEO, demonstrates for us his company's concept of virtualized identity - providing each enterprise application, both in and outside the cloud, with a token in the format it expects and accepts. His example depicts four classes of prominent Web applications, all of which handle authentication internally, and all of which manage identity criteria for themselves. On paper, they all support some form of identity federation, but in the end they each expect your identity to be "consumable" in a different format, often with varying degrees of content. The challenge for any federation service, Prompt explains, becomes keeping up with the ability to translate identity into the formats all these apps expect, as your business's apps repertoire grows and more identity formats are added to the mix.

The second challenge, Prompt continues, is for the federation service to maintain links between all the different formats, and tie those links to maybe more than one directory service. Microsoft utilizes Active Directory (AD) for Windows, and all of Windows Server's per-user policies regarding permissions and restrictions are tied to each user's AD entry, as well as her Windows password. Oracle Directory Services and Google Apps Directory add their own variations on the theme, even though all are (on paper) implementations of LDAP.

So Radiant Logic's RadiantOne platform, while marketed "as a service," is actually implemented as an "identity hub" whose communication with both cloud apps and on-premise apps takes place with a traditional service (by the Windows Server definition), one that truly does reside on-premise. And while RL gets your attention by marketing its identity service with the hyphens still attached, the actual job of servicing takes place between its virtual directory service component VDS and the applications, wherever they reside. VDS presents a picture of AD to whatever identity system knows how to translate its preferred format for AD.

It's still a federation service, maintains Prompt, because it performs the functions that any other federation service provides. But it does not have to be "architected" by the IT department; it provides this service dynamically. He admits that his company is moving away from the "as-a-service" distinction for RadiantOne's on-premise hub, in favor of the phrase "federation identity service for the cloud." But it's not purchasable as a service, or on a subscription basis. Today, he says, it's not practical to place the hub outside the firewall because of all the synchronization that's involved in maintaining identity (the clock is indeed one factor), "and it could even be quite dangerous. It's not that we don't like the idea of hosting it on the cloud." Reality, he says, mandates that the hub be deployed internally.

OneID

At the RSA security conference in San Francisco last month, a startup company named OneID introduced itself to the community, as well as to several interested journalists. Its concept is not identity federation, which is typically something that is managed on the client side. It's an effort to enable Web sites and Web apps to resolve the multiple identities problem themselves, not by continuing their (futile) discussions on creating (more) standards. Instead, OneID compels service providers to attach JavaScript code to their logins that exchanges their users' passwords with a centralized repository.

Because the exchange process is encrypted, OneID CEO Steve Kirsch explains to us, the repository itself doesn't actually have access to its own contents. So unlike some certain social networks or search engines, OneID itself has no intentions to leverage users' identities as a database unto itself. But the decryption process takes place on the client side.

"When I need to get an attribute and give it to a site, I go get the encrypted stuff from the repository, I decrypt it here, and then I send it to the site," explains Kirsch. "So the site never interacts directly with my repository. The site's always interacting with me, and I'm always interacting with my repository. That's why it's called user-centric, because I'm always in the middle of any transaction."

One of the compelling aspects of OneID's take on identity is that it applies to people. You'd think that would be obvious, but in practice, typical identity federation associates passwords with users' accounts. Although in Windows, accounts are portable across computers, there's still a concept of a "desktop," a virtual device, associated with each user. By contrast, OneID assumes accounts are associated with people. So attributes stored in the repository that may be used to automatically fill in forms (which OneID calls AccuFill), are associated with people who may logically be associated with more than one device at a time. That makes sense in the real world, where people have PCs, tablets and smartphones, and where new classes of apps are transferrable between them.

One upshot of this architecture, Kirsch shows us, is that it enables a cross-device audit trail - a way for anyone, from anywhere, to see who has logged in as him from which device. Kirsch demonstrated for us a situation where a user can remotely disassociate a device that has been utilized to log onto services with OneID. Alternately, a device can be remotely registered into OneID by way of a pairing process that resembles logging in a Bluetooth device. This way, only permitted devices may be allowed to log in as particular people.

Ping Identity PingOne

We've covered PingFederate, Ping Identity's federation system, previously in ReadWriteWeb. Since then, the company has inaugurated its new cloud-based identity platform, PingOne, which may or may not be federation by the traditional definition.

PingOne is a cloud-based implementation of the company's adaptive federation scheme, and it challenges the notion put forth earlier that the component that communicates identity must exist inside the firewall. The new service truly is a service by the new, cloud-oriented standard - literally a RESTful API. Enterprises that already utilize a SAML security infrastructure can simply assert their existing identities to PingOne; otherwise, as Jonathan Buckley, Ping's VP for on-demand business, tells us, Ping provides alternate tools through which existing apps are effectively rerouted to PingOne for identity.

"You don't even need hardware, software - you don't even need to know what SAML stands for," says Buckley. "However you connect to it, PingOne multiplexes that assertion such that you can connect once and be able to reach many customers or applications. This is where the cost and complexity of federation held back standards-based federation from penetrating meaningfully into the mid-market in the past couple of years."

While very large organizations have already supported the SAML standard, and continue to, Buckley says that in cases where 100 or more connections are made simultaneously, on-premise federation can be too tasking. "In the end, we found our biggest customers said, 'I would like to make these ten directly, but is there a way I can get out of doing the one-to-one-to-one-to-one networking for all these departmental applications, or for my customer applications?' And that's where PingOne comes in.

The upshot of this new scheme is a feature called CloudDesktop, which effectively extends identities for multiple popular cloud apps onto a control panel that can be accessed from iPads. Here, the desktop provides the single sign-on system. But as Ping's director of product management, Sateesh Narahari, tells us, it's up to the administrator to enable each user's paths to enterprise apps, putting IT back in control.

"The way PingOne solves the problem of one-to-one connections is through multiplexing by using SAML," says Narahari. "The task of multiplexing and managing connections is something that the administrator does." When the admin does set up connections to 100 different SaaS vendors, each one requests a different set of attributes. The admin can use the PingOne console, he explains, to define each attribute set. The end result is "an easily consumable cloud desktop that's built for the cloud generation," that the admin can designate for specific employees. "End users do not need to know that those connections are multiplexed connections."

"With PingOne," remarks Buckley, "we said, 'How is it that we can drive towards a sort of Fisher-Price simplicity?' In IT, everybody attempts that... But with our 49 beta customers, it seems that we've dramatically driven down the time to implement and the sophistication required to grok what is going on and then implement it for the company. You can stick with standards, stick with best practices, and leverage technology to make things simpler, versus putting time into developing a password vaulting solution - which we've always been tempted to do, because sometimes things are hard. And then we found a way to have... better security, better convenience, without so much of the hassle for that mid-market company."