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.