This section includes our latest project report, the project start date, the projected project ending dates, and earlier project reports.

Project Report, 11/98

SUMMARY: The DCAS Distributed Authentication solution is now functional for a very wide range of services, including the World Wide Web, USENET news, and FTP. This report concentrates on Web implementations, because that appears to be the primary area of interest. 29 web servers (about 6% of all UC Davis web servers) are now using Distributed Authentication in pilot tests. Between 2,000 and 3,000 members of the UC Davis community (about 10% of those with Kerberos IDs) are authenticating themselves each week. The only cases in which the software does not provide a complete solution are those where a limitation of the underlying hardware, operating system, or server software imposes a barrier to the implementation of standard authentication methods. Efforts are now focused on documentation and formal rollout of the service.

A set of frequently asked questions and answers can be found at http://distauth.ucdavis.edu/faq.html. One particularly common question is, "What design principles were used in designing the solution?" In order to provide true infrastructure support, the distributed authentication system must be a general-purpose solution to a general problem; therefore it was designed as a gateway function, without dependencies on backend server or database processes. It doesn't matter how complex and interactive the backend server processes might be; once a user passes through the gateway (with success indicated by setting an environment variable), the authentication process has been completed, and has no further effect on user interactions with the server.

If the solution is tailored to each potential backend server/database combination, a customizing burden is introduced that would add significant and expensive programming overhead for each backend/database combination; and worse, every time these were upgraded, the custom solutions would have to be reworked and tested, which would result in prohibitive costs for implementation and maintenance. Individual departments with specialized needs (that make it worth a department's investment of resources) can develop their own customizations. It is not appropriate for central campus resources to be invested in custom solutions. DCAS staff will continue to monitor the currently unsupported combinations, in order to assess campus level of adoption, and to respond if the situation changes (e.g., the server software is upgraded by the vendor to support implementation of standard authentication methods.)

Specifics:

Authentication - restrict access based on access control list or Kerberos authentication

Security - provide a secure means of verifying that a specific remote user is, in fact, who they claim to be

Logging - maintain a record of all authentication attempts

Performance - work well on a high-volume server, without imposing a significant perfomance penalty

Middleware - provide authentication information that can be used by middleware to make authorization decisions

Passthrough - allow unauthenticated users to pass through the authentication process to middleware, so that the middleware can make some information available even to unauthenticated users

The following combinations of operating system and server software support the entire functionality of the distributed authentication solution, with no compromises at all:

UNIX (any common variant) UNIX (any common variant) UNIX (any common variant) UNIX (any common variant) UNIX (any common variant) Windows NT

NCSA httpd Apache Netscape Server Stronghold CERN Netscape Server

Windows NT - Internet Information Server with ISAPI
This configuration will not support authorization decisions at the middleware level. ISAPI stands for Information Server Application Programming Interface. It is the software that mediates between IIS and external processes, such as the authentiation software. The ISAPI is not capable of setting variable values that can be passed to the middleware. This capacity is available in virtually every other web server interface, and is generally considered a standard feature of a programmable API. The use of a variable called REMOTE_USER is the standard mechanism by which authentication information is passed to middleware for additional authorization decisions. ISAPI is incapable of setting this variable, and therefore cannot communicate authentication information to middleware. In addition, the ISAPI does not allow external configuration files to be read by the authentication module. This makes it impossible to specify a location for log files, rendering logging impractical. Distributed authentication works well for IIS servers with ISAPI in high volume environments where there is no need to perform authorization on a per-user basis, and where logging of authentication attempts is not critical.

Windows NT - Internet Information Server with Perl
This configuration will not work well in high-volume environments. Windows NT imposes a significant performance penalty to launch a program from within another program. Using the Perl modules to perform authentication will give an IIS server access to all the features of the distributed authentication solution. However, because of Windows NT's architecture, the process of calling the Perl modules from within IIS will slow the server down significantly. Distributed authentication will work well for IIS servers with Perl modules in lower-volume environments, where the performance penalties extracted by Windows NT are not problematic.

Windows NT - Apache
The Apache server for Windows NT also makes use of the Perl modules for authentication, and is subject to the same limitations as the IIS server with Perl modules.

Macintosh OS - any server
The current version of the Macintosh OS does not provide true multitasking or protected memory. This makes the Macintosh an inappropriate platform for high volume servers, and has nothing to do with distributed authentication per se. There is no software available to allow a Macintosh to mount AFS (Andrew File System) directories. The information used to provide the highest level of security to the authentication process is stored on an AFS server. Since the Macintosh cannot mount the directory where this information is kept, the Macintosh cannot be used for very secure authentication. Distributed authentication works well for Macintosh servers in lower-volume environments, where only moderate levels of security are needed.

Rollout Plans:

http://distauth.ucdavis.edu/issues/
http://distauth.ucdavis.edu/issues/supported.html
http://distauth.ucdavis.edu/issues/middleware.html

DCAS staff is working with other IET staff and technical support coordinators in other departments to develop a series of Recommended Solutions documents that provide information about the range of hardware/operating system/web server/middleware/database combinations that are available, and the implications (authentication capabilities, among others) of choosing each one, and expects to have drafts available for review in December.

Project Report, 8/98

As reported below, generalized solutions have been available for the most commonly-used web servers (Netscape, NCSA, Apache and Mac servers make up together over 63% of campus web servers) on most common operating systems (Solaris, HP, Linux) and for news server authentication (through a web browser) for several months.

Since last month, project team members have been working on Microsoft IIS (which has 9.18% distribution on campus as of Winter, 1997, when the web survey was last done; response of 107). Work is being slowed by the fact that Microsoft IIS does not support standard perl, which was chosen because of its portability to so many different systems. An integrated ISS perl module was found, and is being tested. Project team is at the point of determining whether a custom C based solution will be necessary in order to make the fall deadline.

Three other related functions are now under testing and development

1. The authorization feature is now in pilot phase. For example, the ac4 web page uses this feature to support the "restricted" section, allowing the ac4 page to maintain a directory only accessible by the accounts included in a list maintained by Richard Darsie (an example of locally-maintained authorization lists).

2. Work to generate authorization lists from classlists (Classlist generation for use with the cgi support script through Banner/Mothra interface) is in pilot phase. Classlists are updated nightly for access by the scripts. However, the team must resolve security issues regarding these lists (an even more rigorous level of server-server authentication may be required to address UCD's student privacy obligations with regard to class lists).

3. Support for authentication for access to campus site-licensed software, which may involve multiple cgi's, is also being tested. Project is moving forward well with regard to the ftp and the web-based site-licensed site; the project is stalled with regard to the jukebox (due to lack of system support).

A major communication campaign will be carried out next month, to contact all campus web server administrators, and make them aware of the availability of distributed authentication and authorization services.

Project Report, 4/98

Generalized solutions have been developed, pilot-tested, and are now available for most commonly-used web servers (Netscape, NCSA, Apache), and for news server authentication (through web browser). Mac Web server support alternatives still being tested and evaluated (netatalk project underway). Finally, still recruiting non-IET department with NT server to test scripts, and need to prepare report for analyst to use in defining production-level service for departments to post secure pages in AFS space (new option arising out of this project).

Specialized applications are now under development and testing, including authenticated file download access for licensed software distribution, and restricted web sites with departmentally-maintained access control lists (Richard Darsie, Vet School, and Internship/Career Center pilots). Work continues on kiosk environment.

Team is now working on final communication phase of project, which includes explanatory web page development (revising/consolidating web pages explaining newstyle logins and kerberos passwords), TSC presentations (3/26 and 4/23), notifying users of news server authentication option, and developing recommended solutions page (target audience: TSC's), explaining authentication/access options in a security context. Information will also be prepared for next Bovine-OnLine release.

Project Report, 11/97

Programming is complete for SecureWeb/kerberos ticket creation and flag file system for AFS space (with alternate, hash function of IP address), and server side software has been installed and placed into production.

Server side program is complete for use of Netscape API/SecureWeb; for non-Netscape servers (Apache and NCSA), CGI method utilizing PERL scripts has been developed.

Beta tests are beginning on HP, Solaris, and NT servers this month.

Start Date

February, 1997

1/98 for web services

1/98 for USENET news

3/98 for other applications

Previous Project Update, 6/97

The solution must be based on a commonly-used infrastructure for multiple applications. Ideally, a solution based on the transport layer would be best, but that alternative has been explored and is not feasible at this time. It would involve distribution of specialized client software, which would be complex (installation on every faculty, staff and student machine on or off campus) and very expensive (initial estimates are $100/client). In addition,client software has not been developed for every platform. A solution that is centralized (i.e., put all web pages on a few centralized SecureWeb servers) is also not be feasible, due to the distributed nature of web servers on this campus. Therefore, the solution must also be scaleable and distributed. The proposed solution is implemented at the application layer.

The proposed solution involves using a SecureWeb server to carry out kerberos-style authentication, and to utilize a distributed file system (AFS) to provide access for all authorized servers. Departmental web administrators can choose from low-level security (Kerberos authentication and validated "cookie"), higher level security (addition of AFS file check), or even more customized services (addition of check against local database).

Team is also exploring Netscape certificate services as an alternative high-level security method.