Restricting Access to your Web Site
The purpose of Distauth is to replace IP-address-based authentication with an equivalent that is transparent, scaleable, and distributable. This concept raises these general questions about authentication:
- Why should access to my documents be restricted to UCD?
- What kinds of UCD documents require restricted access?
Controlling access to certain campus on-line resources has become increasingly important, in order to protect copyright agreements, software licensing and distribution agreements, intellectual property, and student privacy rights. Specific examples include:
- Software distribution: If you are distributing software via your Web site, and the software is licensed for use at UCD only, the directory should be secure.
- Classroom materials: If materials have been developed for classroom use, and that material may subsequently be used in a book, the directory should be secure.
- Databases: Databases may be licensed. The library's Melvyl database is a good example of a database with restricted access.
Recommended Security Feature
We highly recommend that you employ a security level that cannot be easily spoofed. Using the recommended
security option, the contents of the cookie is compared with the contents of a file written in
AFS file space. IBM's AFS client software must
be installed on the Web server if the Web server is to read the contents of the AFS directory where the file
is located. This software is available, currently with no charge, for UNIX-based platforms.
IBM does not manufacture AFS client software for the Macintosh.
The following variables set the protection level in the distributed authentication scripts:
- Netscape NSAPI: useafs, afsdirectory
- Perl CGI: protect_level, authdir
- IIS ISAPI:requires AFS protection
Further Security Considerations:
- Secure your Web server. Is the Web server in a location where it cannot be easily accessed? Is remote server access limited to individuals who are maintaining the service? If not, are the read/write access permissions secure for the cgi-bin directory and restricted access directory
- Separate the restricted directories from the unrestricted directories. Web content directories where content is to be restricted should not be part of the primary document tree. If, for some reason, the script fails or is removed, the restricted directory would become accessible.
- Consider restricting access by the campus search engine. Keep an unrestricted introductory page that can be searched, but prefer to add the .norobots option to the restricted directory.