Single Sign-On Products

EDITOR'S NOTE: The Buyer's Guide summarizes vendor-submitted information. To find out about future Buyer's Guide topics or to learn how to include your product in an upcoming Buyer's Guide, go to http://www.winnetmag.com/buyersguide.

In many organizations, users struggle with having to sign on multiple times to access different applications, Web portals, and servers. As the number of mandatory unique sign-ons grows, the burden on users to remember numerous usernames and passwords increases. The result is often unhappy users who innocently create serious security breaches by writing down usernames and passwords because they can't remember them all. Frustration might also extend outside an organization. Business partners, field representatives, and customers might need to access multiple Web portals or applications from outside the organization (typically over the Internet), and they might also be subject to multiple sign-on requests.

Unfortunately, reducing the need for multiple sign-ons isn't a simple task. The products that address this problem use one of two approaches:

The primary purpose of enterprise SSO and Web SSO products is to arbitrate between the user and target applications. If the user accesses an application that requires a separate authentication, the SSO product must do one of two things: pass the initial user credentials to the application for behind-the-scenes authentication or map the user credentials into a different set of credentials that it passes to the application for behind-the-scenes authentication.

In a heterogeneous server environment, credential arbitration depends on many moving components. Terminal emulators need to pick up credentials and emulate the sign-on process for the host. Scripts handle applications that demand a separate sign-on. And you need to have username/password synchronization software in place to keep different user repositories current and synchronized. All these components bring to the table technical nuances that make SSO difficult to achieve.

Reduced Sign-On
Although SSO products provide clear benefits to end users, they might present security risks to the IT organization. For example, standardizing on one username and one password across all servers and applications increases the risk of a security breach. A successful AD attack could enable an intruder to penetrate into multiple servers quite easily if the servers all share the same authentication credentials.

Because of such security concerns, many IT organizations have taken the alternative approach of reduced sign-on. With a reduced sign-on approach, IT organizations determine which servers and applications can share a common sign-on, which servers and applications require a separate sign-on that uses the same user credentials, and which servers and applications require different user credentials.

A reduced sign-on approach is a less than perfect solution from the user's perspective. With reduced sign-on, a user signs on to a desktop or Web portal and can access one set of applications and server resources without having to sign on again. However, some applications or server resources might require additional sign-ons with the same username and password, and another set of applications might require additional sign-ons with a completely different username and password.

Reducing users' sign-on complexity problems requires a balance between user satisfaction and security. If the scale swings too far toward security when trying to prevent a breach, user satisfaction decreases. Similarly, if the scale swings toward user satisfaction, you can compromise IT security.

Selecting an SSO Product
If you decide that an enterprise SSO or Web SSO product is right for your organization, you must determine which one is a good fit for your infrastructure. For example, you need to verify that the enterprise SSO product supports the desktop environments you use. You want to make sure that any Web SSO product you're interested in will integrate well with your portal infrastructure (e.g., Microsoft IIS, Sun Microsystems' Sun Open Net Environment—ONE, Apache). In each case, you need to evaluate whether the sign-on product supports your target platforms and applications. Finally, you must make sure the SSO product you choose can support mainframe applications.

Windowscentric enterprises should also evaluate how an SSO product integrates with Active Directory (AD). SSO products that can leverage AD as their authoritative user directory will provide the best integration. Conversely, products that force you to implement an alternative directory will complicate your infrastructure and might require you to implement additional solutions, such as metadirectory or user-provisioning products, to synchronize accounts between AD and the SSO directory.

Make sure to closely examine the product licensing structure. Most vendors prefer to offer per-user licenses (often with additional per-connector licenses), but most enterprises prefer to purchase under a per-processor or a tiered pricing structure (i.e., you pay a fee for a certain number of users). Be prepared for heavy negotiation to achieve a fair pricing structure, and keep in mind that obtaining competitive bids from several vendors is essential to the negotiation process.

To see this month's Buyer's Guide, click here.