Single Sign-on

Logging on is hard to do, especially if you need to remember a different user ID and password (or pass- phrase) for each different system or resource. If you use passwords that are easy to remember or a single password for all of your accounts, security specialists wag their fingers: "Easy to remember" also means "easy to guess." The experts warn against reusing passwords and writing those passwords down anywhere that an attacker might find them. Oh, yes, they add that you should change each of your passwords frequently.

Thus, it's little wonder that IT managers have been embracing the idea of single sign-on (SSO) services in recent years: Administrative and support costs can be significantly reduced when users have only one password to forget, and the overall environment can be made more secure.

What Log-on Entails

Although the process of logging on to a system seems simple—enter your user identification name and then your password—it actually sets several actions in motion. The first, authentication, occurs when the system verifies that the entity (person or program) logging on is the entity associated with that user identification, usually by matching the password with the user ID [QuickStudy, March 27].

Authorization comes after the user is authenticated and tries to access the system resources. The user may be authorized to view files but not to delete or modify them. The system responds to unauthorized requests with an error message and responds to authorized requests by allowing the desired access.

The actual authorization might happen immediately after authentication, with the client getting a list of authorized resources. Or the authorization might be interactive, with the server denying or allowing access to individual resources when a user first tries to access them.

In technical terms, SSO lets a user log on to a primary domain but have access to other, secondary domains. For example, a Novell NetWare network might represent one domain, a Windows NT network another, an IBM mainframe yet another and so on. Under normal circumstances in multiple sign-on environments, the user must log on separately to each secondary domain.

With SSO, the IT manager specifies a particular platform as the primary authentication domain to control access to all domains. When a user logs on to the SSO primary domain, he provides all the credentials he will need to log on to any of his secondary domains. The primary domain then takes care of authenticating the user to the secondary domains.

At its simplest, SSO is implemented so that each user has an account with an authentication server, which stores all user IDs, passwords and other account information. The server authenticates the user once and then passes user ID and password information to other domains as needed.

This approach simplifies things for users, who need to remember only one password. Unfortunately, it doesn't help administrators much, because they must still set up separate accounts for each user on every authorized domain and manage each domain's authentication information separately.

A better approach to SSO lets IT managers tighten security and reduce overhead costs while making users' lives easier. Instead of hiding a complex multiple sign-on environment behind a single account on an authentication server, more advanced SSOs implement security through policies that determine a user's access in different domains.

Managers set policies for individuals and groups that allow appropriate access to network resources. For example, one policy might authorize customer service clerks for read-only access to a departmental Windows NT network, while another policy might give root privileges on corporate Unix systems to senior system managers in the IT department.

When users log on, the SSO determines what policies apply to that particular user ID. After that, the SSO vouches for the user to other systems.

For example, a programmer would be given access that's appropriate for his position, department and current projects. If an attribute changes—say, the programmer receives a lateral transfer—only the SSO system needs to be updated. The next time he logs on, he's automatically locked out of his old department's systems and given access to his new department's systems.

Ensuring Secure Log-ons

Because SSO involves granting a lot of access rights, it's important that the single authentication process is secure. One way to ensure this is to forgo static user ID/password pairs in favor of digital "tokens," such as the SecurID card from Bedford, Mass.-based RSA Security Inc. These tokens create different single-use passwords for every log-on that are transmitted securely across networks. This makes it virtually impossible for attackers to sniff usable passwords. Token-based authentication also prevents attempts to bypass the SSO and log directly on to secondary systems.

Password/user ID pairs are also encrypted (often with Kerberos [QuickStudy, July 3]) to prevent sniffing attacks. SSOs can also support two- or three-factor authentication, combining passwords with tokens or even with biometric authentication tools.

Centralizing authentication and authorization also simplifies cleanup when an employee is terminated. Instead of tracking down all the systems and resources to which an employee might have had access, managers can simply remove the employee's SSO account.

On the downside, an SSO can represent an attractive nuisance as well as a single point of failure for network security. It may also take a lot of work to establish access to all network resources in an organization, but for many in IT, the benefits are worth it.

Loshin is a freelance writer in Arlington, Mass.


SSO in Action

Once logged into the SSO server, users can access all those—and only those—resources for which they are authorized, as determined by system security policies, without further log-ons to those individual systems, applications, resources and networks.


Copyright © 2001 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon