The Intranet Development Team has built new centrally-provided computing services that unify a multiplicity of accounts, electronic mailboxes and file systems provided by OpenVMS mainframes and building servers running Digital Pathworks. The Intranet design began in May 1996 and produced a fully-functional prototype demonstrated in August 1996. Beta testing of the environment began in Spring 1997 and involved 2500 users through Summer 1998. A production-level hardware platform was acquired in June 1998 and service to the entire Cal Poly Pomona community began in Fall 1998. The platform is built to serve 30,000 users.

Innovations include central authentication, a distributed file system (DFS) and distributed access control provided by the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), integrated with existing electronic mail, the University database, the Cal Poly Pomona Web, and Windows and MacOS file sharing.

• Innovations
  • Central Authentication
  • Distributed File System (DFS)
  • Distributed Access Control
• Integration with Existing Services
  • Electronic Mail
  • University Database
  • the Cal Poly Pomona Web
  • Windows and MacOS File Sharing

Innovations

Central Authentication

In the legacy environment, separate computing systems maintain separate accounts, so users must possess multiple accounts and passwords to gain access to various computing resources. At Cal Poly Pomona, separate accounts are maintained for the instructional and institutional OpenVMS clusters, the campus mail and name servers, the campus news server, numerous Pathworks building servers, dozens of Windows NT and MacOS servers, various database machines, and PPP dialup Internet connectivity. In the Intranet environment, every student, staff member, faculty member, and administrator has one account in a central DCE Security Registry, and access to various resources provided by many computing systems is granted by verifying a user's identity in the Security Registry. This approach gives each user a single account, reduces account management overhead by unifying accounts, makes the resources of many systems available to users who might not have previously sought or been given a bunch of accounts, and makes tractable the problem of providing and controlling access to a large, transient (and sometimes mischievous) population.

Since people work in groups, the DCE Security Registry provides a mechanism for defining arbitrary sets of users called groups. Examples of groups might be students in a class or degree program, members of a committee or club, faculty in a department or college, people with particular database privileges, and so on. The Intranet recognizes two kinds of groups, manually-populated and automatically-populated. As the name suggests, the membership of a manually-populated group is maintained manually by one or more group administrators using an intuitive Web form. For example, the advisor and/or officers of a club might administrate the membership of a club group. The membership of an automatically-populated group is maintained automatically according to information in the University database. For example, the students in a class or degree program would be automatically-populated groups.

Groups serve several important purposes, which are discussed later, but they're primarily used for access control. Each resource in the Intranet computing environment has an access control list (ACL), which is a list of users and/or groups to whom access is allowed. In fact, all accounts are created equal, and additional privileges are acquired by inclusion in groups that are allowed additional access. Account management and information sharing are simultaneously simplified and improved, since accounts are relatively long-lived and widely honored; the account holder simply evolves through group memberships, possibly to become an alumni, an employee, an emeritus or whatever.

Distributed File System (DFS)

In the legacy environment, separate computing systems maintain separate file systems, so users have multiple places where they might put files. At Cal Poly Pomona, separate file systems are maintained for the instructional and institutional OpenVMS clusters, the campus mail and name servers, the campus news server, Pathworks building servers, and every office, laboratory and home Windows or MacOS workstation. In short, there are many islands of information, between which limited sharing and collaboration occur.

The Intranet seeks information ubiquity by building a unified file system that is distributed throughout the campus network and made visible on every computing system, from the centrally-provided computing systems to the desktop and laboratory workstations. The Intranet implements the Open Software Foundation's (OSF's) Distributed File System (DFS), which is based on the Andrew file system developed at Carnegie-Mellon University.

DFS appears to a MacOS user as an icon on their desktop that looks like a local hard drive; it appears to a Windows user as a hard drive, perhaps their E: or F: drive; and it appears to Unix users through the 'list directory' (ls) command. Users of different operating systems in different parts of the community can collaborate on files stored in a mutually understood file system. DFS changes the nature of file collaboration and sharing from an environment that requires copying (or physically carrying) files between island file systems to an environment where all files are available to all users wherever they go, including remote locations throughout the Internet. DFS obviates any need for copying files. A particular advantage of the environment is that students' files are available to them at any laboratory workstation, and they may apply the tools of any Windows, MacOS or Unix system to those files.

DFS includes space for a personal directory for every user, for directories associated with groups that collaborate and produce information, for software and applications specific to the Windows, MacOS, or Unix operating systems, and for the Cal Poly Pomona Web.

Distributed Access Control

Every file and directory in DFS has an access control list (ACL), which is a list of users and/or groups to whom various types of access are allowed. The types of access are read, write, execute, control, insert and delete. read and write access allow someone to read or write, respectively, a file or directory. execute access allows someone to run a program file. control access allows someone to modify the ACL of a file or directory, and is implicitly granted to the owner of the file or directory. insert and delete access allow someone to add or remove, respectively, a file in a directory. Once an ACL is established on a file or directory, it is respected no matter if one tries to access the file or directory through a Windows, MacOS or Unix system or through a Web browser anywhere on the World Wide Web.

Integration with Existing Services

Electronic Mail

Every user in the Security Registry has an electronic mailbox in their personal DFS directory, to which mail addressed to username@intranet.csupomona.edu is delivered. Eventually, the Intranet mail system will replace the bifurcated mail systems of the instructional and institutional OpenVMS clusters, after which mail addressed to username@csupomona.edu will be delivered to a user's mailbox in DFS. Groups in the Security Registry also function as mailing lists. Mail addressed to groupname@intranet.csupomona.edu (eventually groupname@csupomona.edu) is delivered to the mailbox of every user in the group. This is a useful mechanism for distributing mail to students in a class, students in a degree program, committees, clubs, faculty in a department or college, etc.

Mail in DFS mailboxes can be read by any POP or IMAP client (like Netscape, Eudora or pine) by connecting it to any subnet server, all of which are running POP and IMAP servers willing to fetch mail from DFS. This mechanism distributes the load of reading mail, which is currently carried by two central OpenVMS systems, out to every subnet server.

University Database

The University maintains an Oracle relational database that contains information about classes and registration, grades, people, accounts, finances and alumni. In the legacy environment, database information is accessible to coarsely defined groups through an arcane VT interface called Banner, which has repulsed many users. The Intranet seeks to disseminate and collect University database information with finer access control and more convenience through the Cal Poly Pomona Web. This is not so difficult for information that we are willing to share with the whole world, like the schedule of classes, but most of the information in the database is sensitive, and can be made available only to appropriate individuals or groups. The DCE Security Registry provides an ideal means for controlling access to the University database, and the Intranet design seeks to provide authenticated access to database information by integrating the University database, the Security Registry and a secure Web server. For example, the design makes it possible to deliver a student their grades, registration information and transcripts securely through the Web. It makes it possible to deliver a faculty member their class lists. It also makes it possible to securely and confidently collect all kinds of information from authorized individuals.

the Cal Poly Pomona Web

Management of services in the Intranet environment is done primarily through Web forms. There are forms for managing accounts, groups and passwords in the Security Registry. There are forms for managing file and directory access controls, directory quotas, and remote mounting of directories in DFS. There are forms for making queries to the University database. The forms are processed by Common Gateway Interface (CGI) scripts that reside in DFS; therefore, authority to execute any script is naturally controlled by the execute privileges in the script's ACL. This mechanism has proved extremely valuable, and makes it possible to allow even sensitive forms like the creation of accounts to be routinely handled at any Web browser with confidence that only those authorized to process the forms can do so.

The integration of the Security Registry with the HTTP protocol also makes it possible to serve the entire DFS on the Web. Traditionally, directories in a file system are either served through the Web to the entire Internet or to nobody. The Intranet environment ACLs make it possible for file owners to specify exactly who has Web browsing access, and these controls are respected by every Web browser on the Internet. In particular, a student may permit only her professor to browse a file; a committee may permit only themselves to browse a file; any individual may browse private files through any Web browser by permitting only themselves to have read access.

Windows and MacOS File Sharing

In the legacy environment, files stored on the instructional or institutional OpenVMS clusters cannot be directly processed by Windows and MacOS applications; it is necessary to copy a file to the local workstation to do so. The philosophy of the Intranet environment is that the entire DFS (or any subdirectory) may be mounted on any Windows or MacOS workstation using the native file-sharing protocol of the client workstation. This is accomplished through a three-tiered architecture, in which the first tier core contains DFS servers, the second tier subnets contain DFS clients that emulate Windows NT and MacOS file servers, and the third tier contains Windows and MacOS client workstations. The architecture is transparent to the end users; they simply see the subnet servers as native file servers in their locality, when in fact those subnet machines are simply "passing on" the files that originate in DFS in the core.

The integration of DFS with Windows and MacOS file sharing makes it possible for every student and laboratory workstation to have the entire DFS mounted on it, so that students and faculty have direct access to their files in DFS no matter where they go, and they can apply the applications of their favorite workstation platform to those files.