ID 101: Basic Issues in Single Sign-On

ID management eases help-desk overload, user frustration In the October Telemanagement, Gary Bernstein outlined McGill University’s journey to single-sign-on authentication, which continues to this day. McGill’s goal: to abolish the world of multiple sign-ons, with multiple passwords, for the various computer systems the user accesses. No more passwords on Post-it Notes ringing your computer monitor. No more urgent appeals to overstretched IT help deskers for a reset. Single Sign-On (SSO) is the Holy Grail of identity management. It comprises a single username and password combo for the user, so there’s no need to juggle various, and sometimes baffling, alphanumeric sequences to access HR apps, inventory management programs and whatever other systems the -user needs to retrieve. In this issue, Gary explains some of the underlying issues involved in making SSO a reality. Gary is McGill’s director of network and communications services and a member of the Telemanagement advisory board. Single sign-on has three main technical challenges: authentication, authorization, and the user directory. Let’s survey each in turn, and then look at some useful lessons. AuthenticationAuthentication usually comes in one of two flavours: simple (or single-factor), and two-factor. Choosing one or the other depends on how valuable the information behind the authentication set-up might be. The more valuable, secret, or confidential the data, the more authentication levels you’ll want to employ. Each additional level affords that much more protection.Simple authentication is the process of entering your credentials (username and password) when challenged by a system to which you are trying to gain access. Older, legacy systems usually compare your entry against a username-password list created by the system manager and stored and managed by the host system itself. For example, older PBXs function this way. Two-factor authentication requires you to know one thing, for example a credential, and to have something else in your possession before you can gain access to a system. The "something else" could be a semiconductor device that displays a PIN that changes every five seconds and is synchronized with a similar device connected to the host system. Or, it could be an RFID tag that you pass in front of the workstation, or even a biometric signature such as your fingerprint or a cornea scan. The number of factors increases in direct proportion to the value and/or security level of the data being protected. Indeed, some government systems require three-factor authentication because the data are highly confidential. Most, but not all, modern computer-based systems perform authentication by making a query to an external server that contains a database of user credentials (and other attributes)—the so-called "enterprise directory." This approach has several advantages: 1 Ideally, a single credential is stored in a single place, thereby eliminating the user memorization problem. 2 When a new application system is introduced into the enterprise, there is no need to assign new credentials to any existing users. They already exist in the directory. 3 When a password is changed, it is changed in one place, thereby eliminating the need to perform password management on multiple systems. 4 It is an enabler for self-service password reset mechanisms. 5 Consistent password policies can be easily implemented and enforced. For example, the "strength" of a password can be established for all passwords, be they new or reset by the users, and tested against the standard. For example, a typical standard might be that the password must contain a minimum of 10 characters, must contain both upper and lower case characters, must contain at least three punctuation characters, and no part of the password string can be found in the English dictionary. Also, the frequency of change can be centrally enforced. 6 If the enterprise HR database is synchronized with the ID management directory, then a new employee can automatically obtain his credentials and authorizations the moment he joins the organization. 7 Similarly, when a user leaves the organization, his credentials can be immediately disabled on all systems he accesses—or used to access—when his new status is noted in the HR database. This is an immeasurable security benefit. Authorization Authorization takes place after authentication. Once it is established that you may have access to a particular system, then most systems will want to know what resources you have permission to access. For example, if you are a user of a voicemail system, you may be able only to access your own mailbox and change your own password. If you are a "Level 1" administrator, you can create, enable and disable new mailboxes and create system distribution lists. A Level 2 administrator is authorized to change system parameters, perform backups, etc. Once again, some systems judge a user’s authorization level by comparing the credential against a list of local- (or "host- ") stored authorization levels and usernames. More modern systems can utilize the directory, which can also document users’ roles. These systems can then apply local rules against the externally stored roles. A role change gets reflected in the enterprise directory, and thus no changes are required to the application system. LDAPUser identification objects can be stored in any database, but it’s vital that the data elements can be retrieved quickly by the applications that require them, and that there is a schema that defines the meaning and format of each database object. The initial OSI directory standard known as X.500 was complicated and difficult to implement. The University of Michigan streamlined the standard and created a quasi-standard known as the Lightweight Directory Access Protocol (LDAP). LDAP directory servers are the glue that binds applications to directories and are used by most enterprises today. Applications that can access LDAP directories "out of the box" are known as "LDAP-compliant" or "LDAP-aware." There are many different versions of LDAP. "Open LDAP" directory software is free (or bundled with some Unix and Linux operating systems) and is distributed by several organizations. An LDAP directory server consists of a standardized but user-extensible schema plus a database engine that is optimized for fast retrieval of directory objects, callable functions that provide the authentication process, functions that provide data stored in the directory to application systems, and system administration tools. Microsoft’s Active Directory (AD) is a supercharged version of Open LDAP. Among other things, it contains proprietary extensions that add to LDAP’s functionality, but any LDAP-compliant application can use AD as its directory. Many Microsoft products, such as Windows 2003 Server, are able to run only with the proprietary AD extensions. Similarly, there are non-Microsoft applications that require AD, not just vanilla LDAP. Another popular LDAP directory is Oracle Internet Directory (OID). As with AD, there are many Oracle-based applications that will work only with OID and not Open LDAP or AD. One important benefit of using LDAP directories for authentication relates to security. At the authentication stage, an application can be said to "bind" to the directory. This means that the application, for example a voicemail system, first sends the username entered by the user to the LDAP directory engine. If the user exists in the directory, then the application will next send to LDAP the password entered by the user. LDAP will return a "success" token to the application if the username/password is valid or a "deny" token if invalid. The key point here is that the application will never know, and hence never be able to display the user’s valid password. This makes it very difficult for hackers or even corporate system administrators to get access to password information. Also note that credentials are almost never sent over the network in clear text but are encrypted, which makes it extremely difficult to sniff passwords as they traverse the network. LDAP Data The utility of LDAP directories extends well beyond authentication and authorization. Organizations use them to give applications quick access to many different kinds of identity information, which may include objects such as:Usernames Passwords (encrypted by some) Roles Organizational units Digital photos Employee numbers Email addresses Phone numbers Anything else required for identification purposes For example, at McGill we use a commercial HR application called Nakisa that extracts data from our central HR Oracle database and provides a graphical hierarchical view of organizational data. All of the data, including employee photos, are loaded into AD for fast retrieval and authorization purposes. A graphical view illustrating reporting structure and salary history is presented to each user according to his role in the organization. Thus, the principal is able to view the entire organization while I, as a director, can see only the data that is relevant to my department. Nakisa relies on calls to AD to determine the user’s role, and hence his authorization levels. How LDAP Is UsedIf you think LDAPs have utility only in the "application computing" realm, think again. Increasingly, telecom systems and devices are based on building blocks that rely on IP servers and terminal devices. For example, it’s not uncommon for most organizations to own one or more of the following IP-based systems/devices: > IP-PBX > IP voice mail > Call centre > IP phones > Unified Messaging System (fax, voicemail, email) > Access control (card-swipe system) > Wireless LAN > Multifunction scanner/printers/fax machines At McGill, we use LDAP authentication and authorization to provide access to most of these. One intriguing benefit was recently discovered while testing a new Hewlett-Packard multifunction printer/scanner/fax machine connected to the IP network. One can scan a document and email it directly from the scanner to anyone whose email address is contained in our AD. You just type on the local soft keypad the first few characters of the recipient’s name and, voilà, all the matching entries in AD pop up on the printer’s LCD screen. You "click" on the correct one using the touch sensitive screen and the scanned document is dispatched. No fuss, no muss. Our sysadmins no longer have to batch upload files containing user credentials or worry about adding or deleting user IDs and passwords on any of these systems. One change to the central LDAP is all that is required. Non LDAP-Compliant AppsIt would be nice if every application you purchased was LDAP compliant, but this just doesn’t happen in the real world. Many older, legacy applications were built before LDAP was even invented. Is all lost? Not by a long shot. It is possible to build or buy ID management tools that allow system architects to leverage central LDAP directories by interposing specialized software between the LDAP server and the applications software server. For example, at McGill we have purchased Novell’s Nsure product, which simplifies the creation of a metadirectory composed of credential information derived from all of our enterprise systems, some of which cannot directly use the data already stored in AD. Other Nsure tools (or sometimes homegrown scripts) allow us to fool legacy systems by passing to them the credentials that they expect, even though the user has entered the single credential stored in AD. The net result, from the user’s perspective, is that he has a single enterprise credential. SSO and TelecomEven if you are responsible in your organization only for telecom systems, it’s important that you understand these concepts in order to purchase new communication gear or use existing equipment more effectively. Some of the benefits that you will realize are: Enhanced security: Stronger passwords, encrypted credentials, and immediate access denial on all systems to employees who have been dismissed. Reduced management effort: Changes in employees’ status or credentials, made and maintained in only one place (the LDAP), immediately become available to all systems that utilize LDAP. Better customer service: Users do not have to remember multiple credentials, and many ID management systems provide for self-serve password reset. Traps and HazardsIf your role is not to implement or manage the central ID management structure, but to use one provided by your IT department, there are a few things to look out for:When purchasing any new system, insist that it is LDAP-enabled. If your organization uses Open LDAP, then be careful when vendors claim their product is LDAP-compliant. Some of these applications will require proprietary functions only provided by directories such as Microsoft’s AD. Establish a Service Level Objective (SLO) with your central IT department that details things like scheduled maintenance periods, guaranteed availability, and guaranteed response time of the LDAP server. Get buy-in by departments other than telecom that may need to participate in these processes. Document all optimal dataflow, data ownership and data security issues with other departments such as human resources, IT and accounting. Map business processes that create, modify and delete identification data. Be sure not to underestimate the last two points—dataflow and business processes—both of which pose difficult and ongoing challenges. And remember: despite all of its benefits, authentication/authorization using a central LDAP server is susceptible to single-point-of-failure unavailability. Prepare for this type of failure by providing a limited form of local authentication. I would like to thank Marc Huffstickler, the NCS team leader for ID management, for his comments and suggestions in the preparation of this text. —GB

ID 101: Basic Issues in Single Sign-On

News | 10/26/2005 4:00 am EDT

To keep reading, get a free trial.

Already a Subscriber?

Reuse & Permissions

Inside The Wire Report

Information

Hill Times Publishing

Get in Touch With Us