The Challenge of Single Sign-On

Maintaining security with a single sign-on through a Web portal is often a complex problem, especially in a college or university environment, where roles often overlap or change. Here, Rick Mickool reflects on the issues Northeastern University faced in its implementation of a single sign-on.

Like many higher education institutions, Northeastern has realized great progress in making information and electronic services available on the Web to our community members. However, simply Web-enabling our systems did not bring about the level of ease of use we wanted to achieve. For example, information that a student needs for routine curricular and co-curricular support resides in disparate systems including registration, e-mail, library, financial aid, and many others. Before we implemented single sign-on, accessing the information in each system required a separate authentication and authorization scheme. This required users to log in and out of multiple systems, and remember a variety of usernames, passwords, and even URLs. This was a cumbersome and frustrating process. Even worse, the dissatisfying experience often dissuaded our constituents from using the new services that Northeastern was promoting.

To overcome these issues, Northeastern implemented a portal with single sign-on capability. Today, our portal presents users with a single point of entry to a rich array of information and services, including administrative tasks like registering and paying for courses, and accessing course management systems for online learning. The complexities required by the separate systems are handled behind the scenes and are no longer the burden of the end user. Also, the common look, feel, and navigation of the single sign-on environment make it easier for users to find what they are looking for in the portal. These capabilities have greatly increased the ease of access and the breadth of services readily available to the Northeastern community. As new services are Web-enabled, they are presented to users within this familiar environment without any disruption. As a result, we have experienced a significant increase in usage of the services offered through the portal, and new offerings made available through the portal are readily adopted without added publicity on the part of the institution. While the single sign-on capability was essential to enabling the full potential of the portal, achieving this transparent level for users was quite complex.

The objective of a single sign-on environment
is to require the user to authenticate once.

The challenges that Northeastern faced were centered on authentication and authorization. Authentication is the process wherein a network user establishes a right to an identity—in essence, the right to use a name. There are a large number of techniques used to authenticate a user: passwords, biometric techniques, smart cards, and certificates. Authorization is the process of determining whether an identity—plus a set of attributes associated with that identity—is permitted to perform some action, such as accessing a resource.

Authentication
The objective of a single sign-on environment is to require the user to authenticate only once. Enabling this requires an integration framework that allows single sign-on authentication throughout all the systems and applications—which are from a multitude of vendors—that are incorporated into the portal environment. Because this area of authentication is still in its infancy and without set standards, Northeastern chose to purchase a vendor solution, SCT Luminis, whose platform infrastructure features provide this integration framework. SCT Luminis has pre-built “connectors” for integrating many common higher education systems into the portal environment. Institutions also can create custom connectors. Northeastern has used the connectors to integrate with Lotus Domino, IBM Websphere, CollegeBoard PowerFAIDS, and Blackboard.

Some institutions choose to build their own portals and minimize their software costs by not purchasing a commercial product like SCT Luminis. A popular choice is the uPortal technology which is a free, open source portal developed by the Java in Administration Special Interest Group (JA-SIG), an independent organization designed to bring together institutions of higher education and companies involved in Java application development. This type of collaboration can work very successfully in higher education. However, uPortal requires that individual institutions develop and maintain their own integration protocols—an investment of considerable time and resources. In addition, standards in this area are very young and fluid. If an institution develops its own integration protocol, it must be prepared to dedicate the resources necessary to stay abreast of any changes.

We chose a vendor solution because we do not have the staff expertise to properly implement an open source solution. We also wanted a vendor to support the integration, and to continue to build on, and take advantage of, emerging standards. In addition, selecting SCT Luminis d'es not preclude us from taking advantage of the uPortal collaboration initiatives since Luminis uses, and SCT contributes to, many of the uPortal specifications.

However, even integrating with a vendor solution requires upfront research on the part of the IT staff to effectively plan the integration effort. An institution needs to become familiar with the strengths and weaknesses of the integration framework that they purchase or build. Staff must learn about potential integration requirements based on the authentication method of an institution’s various applications and plan an optimized approach to integration. Frankly, some of your applications might not work with your authentication method. In these cases, you will have to negotiate with the vendor of the individual application alter their solution. Otherwise, your institution will need to alter your integration framework to adapt to the vendor.

We found forums like EDUCAUSE and Internet2 very helpful to our research efforts. Our commitment to supporting industry standards like LDAP and SAML helped to minimize these integration challenges. Once the initial research is complete, institutions should begin building the individual connections, constantly making more and more applications available to users with a single sign-on over time, rather than introducing a great number of new offerings once or twice a year. At Northeastern, this approach keeps our portal content fresh and continually increases the value of our investment while limiting the risks of introducing too many complex changes at one time.

Authorization
Single sign-on authenticates the user to the system and verifies that the person is presenting the right set of credentials, allowing the individual onto the electronic campus. Now that they are “on campus,” you need a means to present to them everything that they should have access to—and nothing more. This is the authorization process.

One of the most complex issues Northeastern addressed in this area was defining and mapping service offerings to the appropriate user. For example, recent graduates are provided with access to grades, transcripts, and e-mail for one year after they graduate. However, other services, like registering online for a course or viewing a financial aid award, must be terminated immediately upon graduation. When you consider all the services and information the university makes available, and the different requirements for establishment of an individual’s authorization level, you quickly begin to appreciate the complexity. In addition, those requirements often change.

Giving users a personalized portal experience is based on numerous determinants such as faculty versus student, undergraduate student versus. graduate student, or even undergraduate student taking freshman English at 9:00 a.m. on Tuesday versus 10:00 a.m. on Tuesday.

Northeastern has just touched the tip of the iceberg by doing portal personalization based on high-level role classification—meaning a limited number of student roles. These roles are determined by extracting data from our student administration systems and uploading it into the SCT Luminis platform. The Luminis platform then presents different services to users based on their roles. Northeastern is now planning to deal with the fact that students—and other users—often have different roles simultaneously. For example, a graduate student might also be an undergraduate alumnus. Because the student has dual roles, he or she needs access to information and services relative to both roles, not
just one.

Technically enabling and disabling the variety of services at the appropriate times is only part of the process. An equally large effort is needed to educate internal departments on this issue. Departments must now consider and adopt concrete definitions for how long a service will be made available, and to whom. For example, if a student is on academic probation, d'es he or she still have access to the university e-mail system? What about the ability to pay a book fine? Or request an online transcript? How about accessing online coursework from last term? This approach to services is a new mindset for many people and requires them to answer questions they had not previously considered. It is a challenge for the institution to think across functional areas on scenarios that impact individual experiences.

Another factor that determines service levels is licensing agreements with vendors. For example, licensing agreements with library resources often dictate that only current students can have access at the institution’s rate. Technically, Northeastern could give alumni authenticated access to its library resources, but we are legally prohibited from doing so by our vendor agreement. Thus, institutions need to be diligent about disabling access to resources when user roles change. Understanding and coordinating all these factors, and making sure to provide the right service at the right time to the right people, takes considerable time and effort.

A final area that requires significant thought and research is session management and appropriate timeout periods for services. For example, Northeastern’s e-mail application stays active onscreen for an extended period, even when there is no user activity. This gives users time to think and write thoughtful responses to e-mails. However, financial aid information d'es not remain displayed on a screen for more than a few minutes when there is no activity. An integration framework should account for session management.

Although enabling single sign-on at Northeastern was more complicated than we initially envisioned or desired, it was achievable and has been very beneficial. The single sign-on ultimately delivers more than just ease of use. It also increases the usage of systems and resources, thus increasing returns on our technical investments. Support costs for maintaining multiple passwords and users’ names have been reduced. In addition, integrating various systems into the portal required the creation of common data sets that have reduced data redundancy and our overhead in maintaining all of the systems.

Ultimately, the single sign-on capability at Northeastern has brought definite, and worthwhile benefits for both the user community and the institution.

Featured