Nothing Simple About Single Sign-On

Giving users a single username and password to access all systems is a massive undertaking, but for McGill it has been worth the effort Is this story familiar? You use many computer and telecom systems, each of which demands your username and password (your credentials). You try to use the same credentials on as many of these systems as possible, but invariably, something prevents you from doing so. Often it’s the username format. On some systems, the username is assigned. On others, you may be given a combination of your first and last name, but the limit is eight characters. On still others you choose a username, but if someone else is using the name already, you have to add a number at the end-"GaryBernstein32," for example. Then there’s the password. You probably have one or two favourites, but they must often be modified to match the requirements of the system in question. Then some systems require you to change your password periodically. For example, I used to use the first four characters of my dog’s name followed by numerals for the month and year, as in rufu102005. And of course on some systems where you are both a user and an administrator, you may need two credentials. The bottom line: if you are like most users, you have "secret" locations where you store your lists of credentials. Or, even worse, you may put passwords on PostIt Notes adorning the perimeter of your monitor. Your security department hates you, and you live in fear that your dog may die. Every workplace needs a system that allows users to have one username and one password for access to every application on the network. Absolute Nirvana is an environment where you enter this credential once for authentication on all systems to which you’re allowed access. This is called Single Sign-On (SSO), and it’s the Holy Grail for architects of identification management for enterprise systems. SSO provides benefits for users, system managers and help-desk staff. But like most things worthwhile, SSO is difficult to attain. It requires a solid understanding of directory services, authentication schemas and even human behaviour. Here at McGill, we’re well on our way to SSO. Our experiences could help other IT and telecom professionals implement this useful technology. Single Sign-On ‘Light’We’re at the first stage, which we call Less-Frequent Sign On (LFSO), which has come as a great relief to our user community. We have approximately 50,000 users (including alumni) and at least 25 major enterprise applications to consider, so simplicity is important. We have standardized on a single user ID that mimics the format of our email address: first.last@mcgill.ca. We call this the Uniform Login ID (ULID), and we are enabling the ULID one system at a time. The ULID can be used to authenticate access to all of McGill’s Microsoft file and print services, and to Exchange email, dialup access, VPN access, the wireless network, the call centre system, Nakisa (a commercial human resources application), the Lenel access control system, and our help desk trouble ticket system. The biggies (human resources, student information systems, finance) are scheduled to come on board in October. Achieving a single username/password is still not LFSO-we still have multiple logins. But we have fewer of them, because when a user is placed in the Microsoft Active Directory (AD) domain, a single login provides access to most Microsoft applications (Sharepoint is an exception, for some reason). Also, the user’s login to AD will satisfy other AD-compliant apps. For example, Nakisa will not bug you to authenticate once you have logged into AD. The main challenges are the browser-based applications. Our Oracle-based portal, which will be going into beta soon, provides SSO to all applications behind the portal based on a single log-in. Users will enter their ULID/single password, and background processes will take care of proxying to the target server. We expect to have a complete implementation by the spring of 2006. That will be the true enabler of Single Sign-On. This project has been neither simple nor painless. Here is a roadmap to the process we went through. DiscoveryThe first stage in any ID management initiative is discovery: what systems are in use and how do they authenticate and provide authorizations? In a large organization like ours, the discovery and consultation phase takes a great deal of time, not only because of the wide range of systems not under central control, but also because of the politics involved. Many local systems have traditionally maintained their own authentication schemes and, for various reasons, the people in charge of them are resistant to change. In the second stage we analyzed the authentication requirements of all these disparate systems and chose a product that promises to get you as close to Nirvana as possible. There is fierce competition among the major ID management vendors, such as Sun and IBM, many of whom already provide us with other software. All this caused us some hair loss. We chose Novell’s Nsure, because we considered it "best of breed" and also because it maintained compatibility with most of our major systems. The third stage was to install Nsure and then start writing the connectors to our various systems to create a metadirectory. Think of a metadirectory as a repository, updated in near-real time, that contains the disparate credentials that exist on all systems in the enterprise. The metadirectory is the foundation for all SSO initiatives. McGill does not authenticate directly off the metadirectory; rather we use the data stored within it to create objects in Active Directory, which is currently our authentication directory. Tooling UpNext come tools that provide facilities for self-serve resetting of the passwords. We have just put into production a unique kiosk for this task. It uses two-factor authentication, requiring the user to provide both "something you own" and "something you know." The something you own is the staff-student proximity ID card, really a form of RFID. The something you know can be either the user’s birth date or an answer to a secret question that she chooses when registering as a student or staff member. Here’s how the system works: The user waves the ID card in front of a proximity reader built into the kiosk. If it recognizes the ID card, the kiosk displays the photo we put on record when we manufactured the card. Next the system challenges the user to provide "something you know," which is entered using a touch screen. If both of these are successful, the user may enter a new password and even ask for a printed receipt, similar to the one issued by an ATM, which not only provides the hard copy of the new password, but also contains useful information on what systems the student or staff member can use the password, as well as some "what’s new in McGill IT" information. A similar application will be made available from a web browser, but without the two-factor authentication, which cannot be done from a browser. Then comes the SSO part. For browser-based apps it is fairly simple to proxy the sign-on by an intermediate application that "joins" AD to the target application. The Lightweight Directory Access Protocol provides the glue that binds applications to directories. Non LDAP-enabled client-based authentications need to be dealt with differently, and it isn’t a cakewalk. In some cases these are so difficult to deal with that the strategy is blunt: tolerate them until they become obsolete. For example, we will never achieve SSO on our Nortel Meridian PBX. There remains a need for global authentication, to let users authenticate on foreign networks with their enterprise credentials. In a university, that might mean being able to log into a data source on a remote university’s server using your home university username and password. Federated AuthenticationTechnology exists today that allows you to do it. One approach that McGill adopted is called Shibboleth (http://shibboleth.internet2.edu), which is a project of Internet2, the U.S.-based university consortium for advanced networking. Once the underlying ID management infrastructure has been established, it can be used for federated authentication. The general concept is that applications are "Shibbolized" so that they admit any outsiders to their systems if a trust has been established with the remote organization. Recently McGill Shibbolized its wireless network in collaboration with the University of Toronto and Dalhousie University. We provided them with standardized software that, when installed on their ID management systems, allowed their users who were visiting McGill for a Canadian IT directors’ conference to enter their home credentials to log onto McGill’s wireless network. For a sample of McGill medical documentation now available over this federated authentication set-up, visit www.mmi.mcgill.ca/mmimediasampler2004. On a high-speed line, allow at least 60 seconds for the page to download. McGill is spearheading a pan-Canadian Shib movement whose objective is to have all Canadian universities Shibbolized. Similar initiatives are ongoing in the private sector, using either Shibboleth or another standard called the Liberty Alliance. In the next issue of Telemanagement, I will explain the basic technologies underlying Single Sign-On and provide a few pointers on implementation. Gary Bernstein is director of network and communications services at McGill University.

Nothing Simple About Single Sign-On

News | 10/03/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