Please note: This material is no longer current and appears online for archival purposes only. Use the search and navigation tools above to locate more up-to-date materials, if they exist.

Statement of Direction and Issues
Unified PennNames

Background

Distributed computing at Penn needs to be more useful and usable. A prerequisite of almost every technology we might wish to deploy toward that goal is a database of unique, campus-wide usernames.

For example, faculty, staff and students must often maintain an array of usernames and passwords for accessing desktop computers, electronic mail, general purpose computing hosts, workgroup file servers, administrative applications, Library information bases, and Internet resources with controlled access, such as FTP and some WWW servers.

This is not only inconvenient, but often leads to a number of security vulnerabilities. For example, many people pick easy to remember and easy to guess passwords, or write down their usernames and passwords for each system they need to access, and stick them in convenient and easily discovered locations, such as "Post-It!" sticky notes on their computer monitors. The security problems increase the risk of violations of electronic mail privacy, compromise of academic research data, and abuse of administrative systems such as payroll and student records.

A solution for these problems is implementation of a single sign-on authentication service for Penn. This service must be campus-wide if it is to serve our many enterprise-wide needs, from the Library and ISC-designed administrative systems, to inter-organizational teams, workgroups, partnerships and co-authorships. Clearly it must eventually protect both large and small systems, or users will continue to have multiple usernames, accounts, and passwords.

The most promising technology for supporting a campus-wide authentication service is Kerberos, which enjoys full support from all of our major multi-user host system vendors, and has recently gained adherents, or at least acceptance, among PC and LAN server vendors, including Apple, Microsoft and Novell.

Other desired functions are the ability to receive electronic mail sent to username@upenn.edu, to allow email directory lookups at upenn.edu, and even to deliver email addressed to firstname.lastname@upenn.edu assuming it is unambiguous.

As indicated, before Kerberos or the email service can be deployed, Penn must create a single, campus-wide database of usernames, and develop tools and policies for maintaining the database across campus.

Penn has developed a PennNames Management System, including Application Programming Interfaces (APIs), complete system administrator tools, and the basic policies needed to support migration to and maintenance of PennNames.

Creating the PennNames database

Given a clear articulation of how the University's business requirements and direction have created the need for a PennNames (see above and also our " Business Requirements and University Direction)", a four-pronged, simultaneous attack is being pursued:

• Faculty and IT Leadership Endorsement: To succeed, the University's Faculty and IT Leadership, possibly even at the level of the Provost and the Deans, must embrace the need for a unified PennName space, ratify its rules and policies, and direct their computer support personnel to work with the ISC to create and maintain the PennName space. While participation is not mandatory, there is an important incentive to participating from the outset, rather than joining later. Namely, because it is difficult (if not impossible) to change the campus-wide username assigned to a given user, one of the policies is that user populations who join later will have to change their conflicting usernames, with out regard to status, rank, history, or intensity of use. By participating from the beginning, these considerations can be the basis for negotiating conflict resolutions.

• Policies: Policies are needed to define and limit various levels of trust granted to campus system administrator. Several levels would be required to distribute basic functionality as much as possible, even to relatively untrusted people, while granting exception-handling and oversight responsibilities in relatively few highly trusted individuals. However, to keep things simple enough to implement successfully within a very short timeframe, the design team has chosen to have only two levels, trusted system administrator and database administrator. Trusted system administrator can do the following:
  • For people with PennCards, create a PennName, selected from a list of available names, given the PennCard ID number.
  • For people without PennCards, create a PennName, again selected from a list of available names, given information similar to that maintained by the PennCard system.
  • Assign an arbitrary available PennName to an arbitrary person, for instance the PennName "chip" to "Charles H. Buchholtz".
  • Reserve system names (such as root, system, and admin), and aliases (such as consult, help, chair, dean, and provost) to prevent users from obtaining these as usernames.

  The database administrators can do all of the above, but can also delete and change entries in the database.

  In other words, trusted system administrators can create PennNames in a number of ways, but cannot delete or modify entries, while the database administrator can fix problems.

  For someone to become a trusted system administrator, two requirements must be met. He or she must be "blessed" by the head of his or her school, institute, or division's computing organization, and he or she must be a full-time, professional computer-support staff employee of the University who can work with ISC to resolve any problems that arise in the use or mis-use of the system.

• System Tools: Penn has developed a set of tools for use by system administrators in creating and retrieving PennNames. While these have been targeted primarily at Unix systems to date, administrators of VMS, Novell, AppleShare, and all other multi-user systems are invited to help develop ready-to-wear tools for username and account creation on all these platforms.

  Until such tools are developed, assuming they are necessary, ISC has deployed a password-protected World-Wide Web page and form that will allow more general access to trusted system administrator functionality.

• Building the Initial PennName Space: Administrators of most of the large multi-user systems on campus have bulk-loaded their username spaces into an initial PennName database. The following data was collected:
  1. Hostname;
  2. ID number;
  3. Username;

  The date and time of loading is recorded as well.

The Username Space Problem

By mid-July of 1995, the PennNames database contained entries for 59716 account records, from 11 multi-user systems, including ones in Development, Medicine, SAS, SEAS, Wharton, ISC's pobox, dolphin, and internal hosts, as well as the PennNet Authentication System (PAS), and the online directory. In order to estimate the difficulty of resolving conflicts in this collection, two types of conflicts that stand in the way of a unified username space were analyzed. The "Type 1" conflicts are the more difficult and serious ones wherein two or more different people have the same username on different systems. These will require getting people to change their usernames, and are therefore difficult. 6211 Type 1 conflicts involving roughly 9000 people were identified.

Type 1 conflicts (6211 total):
        | faculty  staff  students  unknown
faculty |    31     204      195      473
staff   |    x      218      462     1204
students|    x       x       422     1498
unknown |    x       x        x      1504

The "Type 2" conflicts are those where single individuals have different usernames on different systems. These should be easier to deal with because people will simply have to pick one of their existing usernames, which actually simplifies their lives, at which point system administrators can change the other names to conform. Type 2 conflicts affect approximately 10,000 people.

Type 2 conflicts (9998 total):
    faculty  staff  students  unknown
      443     1091    6233      2231

These results are based on current account information, but comes from only a handful of systems on campus, and over-emphasizes systems with larger user populations. However, even with these limitations, it is clear that resolving conflicts will require much publicity, understanding on the part of users, the support of providers of computing support, and a significant effort by system administrators.

Fortunately, the newly deployed PennNames Management System has provided the means for us to stop creating new, addition conflicting names, effectively capping the size of the conflicts problem. As many new usernames are being created every semester, we can be reasonably confident that each user will receive a username that is both unique and persistent across the participating systems.

Conflict Resolution

Resolving conflicts will require endorsement by campus leaders, the assistance of providers of computer support, and understanding by users, and therefore extensive communications efforts. To facilitate this communication, and to encourage conflict reconciliation, a number of new services that require unique, campus-wide usernames are being considered.

While the procedures for resolving conflicts have yet to be finalized, the usernames of all initial participants have been collected, and conflicts must now be resolved by several criteria. The criteria presently being considered are as follows:

1. replied and wants to keep name > volunteered to give up name
2. faculty (by rank) > staff > graduate student > undergraduate student > guest
3. older name > younger name
4. more widely used > less widely used name
5. has only one name > has multiple names
6. system name > person name
7. name assigned by PennNames as unique > name bulkloaded later

Conflict Resolution Implications

• The "rank" rule alone reduces the number of Type 1 Conflicts from 6211 to 2175, a 65 percent gain!
• The 10,000 Type 2 Conflicts are expected to be relatively "easy" to resolve, as they arise from a historic quirk of PAS.
• Dummy accounts with .forward files can facilitate name changes.
• Privacy issues remain, but should diminish.
• Name changes can be deferred until forced by users or a "killer application".

The larger number of conflicts to be resolved implies that it will not be practical to resolve most conflicts personally. We now expect to have to use some fairly rigid rules.

Avoiding Further Username Confusion

While it is possible to talk about the differences between PennNames, Network ID's, host system usernames, and file server usernames, there is already plenty of confusion about these different names without adding the concept of PennNames. We are therefore shielding users from the PennNames system, per se. Rather, we are now, in documents like the PennNet Passport, making only a passing reference to the existence of a new system that should make it possible for a user to obtain a single username that is uniquely and persistently his or hers as they obtain accounts for various services at Penn.

Outstanding Tasks, Questions and Issues

A number of tasks, questions and issues remain:

1. Additional campus system administrators must be granted trust and supported as they begin use of the PennNames Management System. This is especially true of smaller schools and organizations that did not participate in the initial system launch. To the extent that they are able to use the Perl scripts already developed, they can join immediately if the organization's Director of Computing can designate a full-time computer support staff person as a PennNames contact.
2. Useful services must be developed and deployed that require unique, campus-wide usernames. Without them, conflict resolution is unnecessary and difficult; with them, conflict resolution will be seen as a small price for users to pay. The ability to receive electronic mail sent to username@upenn.edu, along with support for finger-style lookups at upenn.edu, and delivery of email addressed to firstname.lastname@upenn.edu (assuming uniqueness), are likely to be the first services to become available. Other services that might become available over the coming years are single sign-on Kerberos authentication, and Library database access.
3. As these services are prepared, we must also gain endorsements from University Council's Communications Committee, the Provost and the Deans for the new services, and for resolving PennNames conflicts, including a general approach, and specific rules to be applied. Based on the approach and rules, we must develop tools to support the resolution process.
4. The new services, and the need to resolve conflicts in order to use them, must be publicized in the Almanac, and a number of electronic mail list and newsgroups.

Summary

By participating in the PennNames Management System, system administrators can give their new users usernames that are unique and persistent across campus. Loading pre-existing usernames into the PennNames system, has the same effect if the name does not conflict with the existing, operational PennNames data.

The life of users can therefore be kept relatively simple as they use distributed computing resources, from workgroup to institution-wide services and applications. They also position themselves to take advantage of new services as they become available and are appropriate for their systems and users.

Please note: This material is no longer current and appears online for archival purposes only. Use the search and navigation tools above to locate more up-to-date materials, if they exist.

    pennnames