Authentication

In security terminology, authentication concerns verifying who you are. A popular type of authentication is to restrict access to a web site based on IP address of the browser. Commonly, IP addresses associated with UC Davis are given access to a site, and other IP addresses are rejected. This is a feature that most web servers support. Unfortuneately, using this form of authentication may exclude users who are logging in to your web site via a commercial internet service provider. (The IP address of the commercial ISP will not be recognized as part of the ucdavis.edu domain). The Distributed Authentication Service allows access to your site based on the user's UCDLoginID and Kerberos password.

Using the Netscape NSAPI or the PERL cgi, the Distributed Authentication Service can be configured to perform according to the following senarios:

All users are required to authenticate using their UCDLoginID and Kerberos password.

If your browser is in the ucdavis.edu domain, authentication is not required. If your browser is outside of the ucdavis.edu domain, users are required to authenticate.

Some IP addresses are allowed without authentication, other IP addresses are automatically denied access to your site, and the rest of the users are required to authenticate.

The features controlling these behaviors are:

netscape NSAPI: allow, deny

perl: allow_ucd_ip, allowed_nets

IS ISAPI: All users are required to authenticate

In all cases, the default mode is to use user-based authentication, where the Distributed Authentication Service can be used to verify that a user truly has an account at UCD.

Authorization

Authorization is an additional level of security. In addition to a user having a valid UCD LoginID and Kerberos password, the UCDLoginID of the user must also reside in a designated authorization file. The PERL cgi or Netscape API allow you to maintain or access authorization files. One or more files may be listed; the files are OR'd, meaning any UCDLoginID found in any specified file will be allowed access to your site. (The file format is one UCDLoginID per line).

The features controlling these behaviors are:

netscape NSAPI: user-list

perl: user_list,

IS ISAPI: User lists cannot be specified.

Classlists

UCDLoginID Classlists may not be modifed. To add access by TAs, lecturers, or other individuals, as well as the class members, you may create a text file containing a list of UCDLoginIDs and place that list in a secure location as well.

In summary, here the steps to allow your web server or middleware to read a classlist:

1. Install AFS on your system. (Note that you cannot do this on the Mac).

2. Request that your web server be given access to the classlist directory.

3. Follow the recommendations on the security page.

4. Identify the path to the classlist files that your server will be accessing. Mount the AFS drive, then change directories to /afs/ucdavis.edu/common/authclass. Change directories to the quarter or semester of interest, then look for the class, identified by department name, course number, and section number.

5. Configure your distributed authentication cgi to read the file that you identified in the previous step.

6. If you want to also maintain a list of users who need access to the restricted directory in addition to the members of the class, you can generate and store the file locally. You can identify the UCDLoginID's using the LDAP web page.
   • Set the Find: box to People. (If it is not set to People, hold down the triangular arrow and select People).
   • Enter a name in the format: firstname lastname
   • Click on the search button.
   • In the bottom section of the search window, the search results will be displayed. The UserID field will display your UCD LoginID. If this line is blank, the account has no UCD LoginID.

7. Configure your distributed authentication cgi to read the files that you identified in the previous steps.