The proliferation of usernames and passwords has made single sign-on (SSO) something of a Holy Grail for administrators. The problem, says Omar Hussain, senior VP of marketing and product management at SSO developer Imprivata, is the range of application types that need to be supported, from Windows programs of all kinds, through mainframe or Telnet legacy software, to Web applications that could be hosted internally or outsourced.

Early attempts at SSO were intrusive and required application rewrites or modifications, he says. Typically they involved users authenticating to a central credential server or metadirectory, which then authenticated them to the applications.

"The second way is to do it on the client, for example the way Passport works, or a browser saves your details," Hussain adds. "The problem is it needs work by the user, there is no central management and it's not portable between PCs.

"The third way is distributed SSO - you have a central repository and IT is responsible for enabling the applications for SSO, and then SSO happens based on the user's authentication to the network. Most players are taking that third way because it's the easiest to use and implement - authentication still happens at the user end and it's non-intrusive, with no modifications to the applications."

Several companies now have distributed SSO implementations, ranging from Computer Associates and Novell, to Imprivata with its OneSign appliance, which derives from technology developed by Polaroid's ID card and driving licence division, and Groupe Bull subsidiary Evidian.

Script or learn
Hussain says that there are various ways to perform the actual sign-on. Some use scripting mechanisms to learn the logon process and set up templates, while others such as OneSign use learning techniques that understand how applications do user authentication and can automate the process.

"It's just like Internet Explorer and passwords, but those are simple Web applications and these are complex enterprise applications, legacy applications, third-party Web applications," he says. "It's not as simple as it looks - it has taken our engineers years to do. There could be 10,000 to 20,000 different kinds of app behaviour out there.

"You also need to avoid credentials being intercepted at the desktop - it's not easy at all, it's very difficult to get right. 20 percent of applications are relatively easy, 80 percent are hard. Web applications are relatively easy, but even there you may have Java challenges perhaps. And people don't want 80 percent, they want 100 percent - and the most difficult will always be the most critical."

Nor can that 100 percent be guaranteed, he warns: "We have failed on some. There was one company which used an old 16-bit terminal emulator everywhere." In that case, the only solution was to move the customer over to a newer version of the software.

Pragmatism vs paranoia
He acknowledges the 'Keys to the Kingdom' argument - that storing application credentials in a central repository creates a prime target for attackers, as well as a single point of failure. He points though to the PostIt notes and shared passwords common in organisations today, and says you need to be pragmatic about it.

"Anyone dedicated enough could break something, but we aim to start people off with ten times what they have today," he says. "It should make it simpler to apply biometrics though, and if you're concerned by password borrowing, you buy strong authentication, for example a token, at $30 to $100 per user."

The OneSign device is a box that sits in the network and stores user login details. Then, when next they start the application, an agent on the PC automatically retrieves these details and enters them; it also logs the event and hits OK or Return, so the user simply sees the application open up.

It uses a technique called application profile generation, which is a kind of reverse screen-scraping that identifies what needs to be entered where on the screen.

"Authentication still happens at the user end - it's non-intrusive and requires no modifications to the applications," Hussain says. He adds that, unlike remembering passwords in a browser say, it can work for any application, whether it be an enterprise client/server app, a legacy mainframe app or a third-party Web app. Plus, because the credentials are stored in the network, users can log onto their apps from anywhere and are not tied to a specific PC.

Strong authentication takes control
Adding an app to OneSign is a one-time process for a system administrator. The real user login is then via strong network authentication, such as a strong password, a biometric or a token.

The OneSign logs can also be used to see who is using which applications, as well as to detect users who are sharing usernames and passwords. Hussain adds that as distributed SSO evolves, it will be used for other things too. For example, it could tie into user lifecycle management, with links into account creation and removal and user permissions.

He points out that while tools such as enterprise directory services can log users onto a corporate portal or a set of in-house Web applications, there are still plenty of non-Web apps around, plus you may be using third-party or outsourced Web apps that you don't control.

"In the mid-market, most companies try to do three things," Hussain says. "First, reduce the burden and economic problem of password overload. Second, it's compliance, with strong passwords and who accessed what. And third it's security."

"The number one problem today is identity management. We have created this huge problem with passwords," he adds. "10 years ago, strong authentication wasn't cost-effective, but now the password reset savings on the helpdesk are justifying it."