Strategic Security: Web Single Sign-On

A growing number of services help users manage multiple SaaS passwords.

Inside the firewall, many companies have deployed single sign-on systems to cut down on the hassle of end users having to remember and care for multiple user names and passwords. With SSO, an employee logs in once with a set of corporate credentials (typically a user name and password), and the system automatically signs the person into her other applications.

Now, as companies engage with multiple software-as-a-service providers, they're caught trying to solve the same problem all over again. Case in point is Qualys, a vulnerability management vendor which is itself a SaaS provider. The company's employees have access to about a dozen online applications--and also need to handle that many credentials.

"It's a pain managing passwords across multiple accounts and remembering a bunch of URLs," says Hesh Issa, VP of operations at Qualys.

In the SaaS world, companies have two choices for Web-based SSO. The first is to set up individual connections with each SaaS vendor, so that the same set of user credentials is automatically passed along to each SaaS application. This requires that IT use proprietary APIs from each vendor, or use one or more authentication standards, such as the Security Assertion Markup Language (SAML) specification, an Oasis standard that facilitates the exchange of authentication and authorization data among multiple parties.

The second option is to choose from a growing number of vendors that offer Web SSO as a software package or as a service.

These providers build back-end integrations with a variety of SaaS applications so that companies have to make only one connection--to the provider's service--to enjoy SSO for multiple Web applications. These providers use SAML, other standards such as WS-Federation, as well as vendors' proprietary APIs to enable SSO. Let's take a closer look at three of these companies--TriCipher, Symplified, and Ping Identity.

Sign Me Up
In the SaaS world, most of the activity around identity management focuses on single sign-on. There are two main reasons for this. First, enterprises know that SSO facilitates user adoption of applications and cuts down on the inevitable "I forgot my password" calls to the help desk.

Second, some major SaaS vendors, including Google, Salesforce.com, and WebEx, now support SAML. Last year, Salesforce announced it would enable use of SAML in addition to its own Web services API to let customers create one-off SSO implementations. The company says an increasing number of its customers are implementing SSO, although it declined to provide specific data.

Vendors offering Web SSO are taking advantage of this growing SAML adoption as a building block for their services. One of those vendors is TriCipher, which offers both premises- and SaaS-based authentication products. Its Web SSO offering, called MyOneLogin, was launched in February 2008.

Qualys turned to MyOneLogin for its 250 employees. MyOneLogin provides a Web portal where Qualys' users get icons for all their SaaS apps, as well as several internal Web applications, such as the company's code-versioning system and corporate wiki. Users click on the icon and are automatically signed in to the application.

MyOneLogin supports several options to pass credentials to applications, including SAML, WS-Federation, and APIs from major SaaS vendors. With the SAML option, when a user logs in to MyOneLogin and clicks on an app, the service generates a SAML assertion and signs it with its private key. It then sends the SAML assertion to the SaaS vendor, which verifies it via the MyOneLogin public key. Once the assertion is certified kosher, the user is given access to his application set.

If the SaaS vendor doesn't support SAML or another standard, the first time a user launches an application from the portal, he's prompted to enter his credentials, which the MyOneLogin service gathers up and stores for subsequent use. Some security teams will raise an eyebrow at the idea of having user names and passwords stored by TriCipher; however, the company is quick to point out that user credentials are stored on the company's ID Vault appliances, which are FIPS 140-2 Level 2-rated devices. FIPS 140-2 is a government standard for cryptography devices. The Level 2 designation means the device includes features, such as seals, that must be physically broken to get access to cryptographic keys.

In addition, the service is hosted from -- and ID Vault appliances are stored in -- a secure data center.

Newest First  |  Oldest First  |  Threaded View