| | | |||||||
| |||||||||
|
|
|
|
|
|
|
|
|
|
|
This discussion is intended to clarify some of the issues relevant for campuses that want to provide secure single sign-on to various web-based services, especially in the context of web portals. A system that provides single-sign-on services tends to have twin goals: security and usability. A moderately simplistic but still helpful view puts these goals in conflict with one another: on the one hand, a situation where all information is open and freely available is quite convenient for users, and on the other, a system that makes all information inaccessible is, to say the least, pretty secure. Forgetting the extremes, however, which never really exist, it is important when considering how to provide single sign-on services to understand what compromises, both of usability and of security, are being made. (Keep in mind that single sign-on wouldn't be an objective at all if we just cared about security; there is nothing necessarily insecure about asking a user for different passwords, repeatedly and often.) A third important goal is practicality of implementation; many schools do not have large enough IT departments to implement a wide-ranging security architecture or modify legacy systems to accommodate such an architecture.
Single sign-on is fundamentally about authentication. How can a number of services securely determine a user's identity by virtue of some prior action on the part of the user? What are the minimal steps necessary for a user to establish an authenticated status, and how is this status checked and accepted by services that care? Is network security accounted for? For the moment, we'll avoid considering access-control logic, assuming services can apply arbitrary access-control rules after authentication to determine whether a user is authorized to access its resource; it's worthwhile to consider mechanisms that centralize and normalize this sort of access-control logic, but these concerns are, at least initially, separate from single sign-on.
Given the goals of security, usability, and ease of implementation, let's consider some particular proposals for how to accomplish web-based single sign-on from a portal. For each potential solution, we'll discuss the advantages, the drawbacks, and how much work is involved. uPortal's security architecture is general enough to support nearly all of the solutions raised here easily, but it is not intended as a prepackaged, "turn-key" solution. It is a framework for accommodating existing and new infrastructurs, but it does not attempt to resolve or even address campuswide information security for schools that have not yet done so themselves.
Kerberos, from MIT, is a rich protocol that provides single sign-on for some purposes, but it often does not work with web applications directly. Kerberos requires that code in each client and server to handle secure authentication, and since most web browsers don't have this logic hacked into them, the client requires some other step -- like user entry of a password -- to communicate authenticated status to the the web server. Solutions that involve adding a Kerberos plug-in to web browsers are available, and Cornell's solution, based around a program called Sidecar, is relevant as well.
Kerberos accounts for most issues raised by modern security experts and is appropriate for tightly coupled organizations (while a PKI-based solution would arguably be more appropriate for a more loosely bound group of campuses). However, maintaining a Kerberos installation may involve too much work and a greater support cost that some schools can accept. Running Kerberos as a solution for web-based single sign-on not only requires the setup and maintenance of a Kerberos server; it also requires determining and implementing a mechanism whereby web browsers are made to become Kerberos clients (as discussed above) and, separately, a mechanism for servers to support the architecture as well. Modifying servers is not very difficult if you've written the servers, but it can be all but impossible for a small school to Kerberize a large legacy application or one whose source code is not available.
Integrating a PKI into a school's security architecture is a larger project, and is thus not addressed here.
Yale has developed a software package known as the Central Authentication Service (CAS) that simplifies the implementation of a single sign-on solution for a campus. (Other schools have developed similar software as well.) Yale's CAS is is currently a collection of Java servlets that coordinate authentication activity among web applications that agree to use it. (Details about how CAS works are available at http://www.yale.edu/tp/auth.
CAS is usable with most back-end security infrastructures, but it does not provide its own. As an example, a school can set up CAS to validate usernames and passwords against a back-end Unix password file, a Kerberos realm, a Windows domain or Active Directory, etc. Like the uPortal security architecture itself, it does not solve the problem of how to conduct a "primary" authentication of users -- that is, an initial authentication to bootstrap others; instead, it provides a mechanism for plugging in logic to do so. Once logic is plugged in once at CAS's end, it is usable by other systems by virtue of the fact that they handle their authentication through CAS.
CAS is specifically intended for web applications. It accommodates non-web base services (like email) that have a web-based front end, but this currently requires nontrivial effort. It is far easier to make a dozen locally written web services CAS-aware then to support CAS for IMAP-based email.
For smaller schools with custom-written web applications that currently use different mechanisms to authenticate users, CAS may be particularly appropriate. It provides a secure, efficient, and easy-to-use mechanism for normalizing the process of authentication across numerous applications, and it fits nicely with installation of uPortal as well. (uPortal can be either a client of CAS, like any other, supporting it much in the same way as other standalone applications might -- or it may take a more central place in the picture, making uPortal at least seem as if it is providing CAS's functionality itself.)
It is, however, probably beyond the resource of most small IT deparments to integrate CAS into legacy applications that do not have available source code or are otherwise difficult to modify.
Perhaps the simplest way for a web portal to allow a user to log into a service without requiring the user to authenticate manually to that service is to remember the user's password for that service. This assumes, first of all, that the service in question requires a password or some other reusable authentication token. Those new to enterprise-level security or who are accustomed to relatively small systems have often not considered the fact that passwords are not used in many contexts; as mentioned previously, for instance, Kerberos authenticates users via tiered "tickets," and Kerberized services do not expect a repeatable "password" to be sent to them by clients.
At any rate, this simple solution is currently a mechanism being considered by uPortal. This solution does not represent a security architecture, and it can make an existing security system worse by providing new vulnerabilities. That is, it does not solve many of the issues that security systems attempt to solve; it doesn't, in fact, even try to address them. For instance, network security is often not considered, and if it is, the solution often settled on is to use SSL simply as a mechanism for encryption, ignoring its potential benefits for authentication and access control. (As an example of why this might be detrimental, keep in mind that encrypting a password with a key agreed upon by the source and target system is an effective defense against a network sniffer but not against a compromised or spoofed target server.)
The major advantage of this solution is that it accommodates legacy systems with a minimal amount of local work. It also arguable gives the same surface appearance of a far more sophisticated solution. An existing web-based service, even if it has no knowledge of uPortal and predates it by many years, can be made to work with this system. Essentially, this model treats passwords as simply data to be passed as a runtime parameter to a service. Just as a weather channel might want to know a city for which it is to display meteorological information, a financial-aid lookup channel might want to know a username and password. It also, for that matter, may want some other sensitive information that isn't specifically an authentication token. For example, it may be convenient for some system to ask a user for a social-security number. Because of this possibility, it makes sense for uPortal to have some mechanism for encrypting sensitive channel parameter data anyway. Using this mechanism to encrypt authentication tokens like passwords is, according to one way of thinking, a natural next step.
One problem with storing confidential data (whether passwords or just other sensitive data) in uPortal's database is that this new role for the database suddenly increases its security requirements (and those for the machine it runs on). It is no longer even possibly appropriate for uPortal to share a JVM with anything else less privileged, and access to the database that uPortal uses must be rigidly controlled because the security of other systems is now on the line. The uPortal instance's administrator, as well as those with access to uPortal's database, are now capable of compromising the security of user accounts on unrelated systems. Attempts can be made to avoid this problem, such as encrypting the information that uPortal stores, but these solutions tend not to limit the abilities of a determined administrator. It is likely that no such attempts will be adequate if campus policy does not allow the group managing uPortal to have this level of access; if this institutional restriction is in place, this solution is probably not appropriate. (For instance, this solution may not be appropriate if an unprivileged web team is managing a portal that provides access to payroll data.)
This solution also does not scale well, and it is not always convenient. How are password changes accommodated, for instance? What happens when a particular user's account needs to be invalidated across several systems? What if, as mentioned above, campuswide information-security policy does not allow one department to store passwords used by another department? What if the uPortal's system or database is compromised?
Single sign-on is a convenient mechanism for users, and schools should consider how much work they wish to perform in making it secure. Comprehensive security architectures should be considered by schools where security is considered a priority and where resources are adequate to address the issues that arise. A system like Yale's CAS may be appropriate to provide basic, web-centric single sign-on, but it does not easily accommodate systems that are not web-based, and it also may be difficult to use with legacy systems. Storing numerous passwords in a centralized location and sending them out as needed to various services is never recommended if security is a goal, but it may be the only solution within reach for some IT departments.