Oliver's Guide to Access-Limited Web Pages at MIT

1. Summary

MIT has two main web servers: the official Institute web servers run by Information Services & Technology (web.mit.edu) and the SIPB web server run by the Student Information Processing Board. The front page of both servers is identical. Each server provides a different method of access control to restricted web pages. By using both, one can get a more-or-less complete solution (see caution about encryption and data security below).

The official MIT web server allows one to limit access to specific users or groups via MIT web certificates. For now, such certificates are only available to members of the MIT community. This access control solution is therefore useful for pages that are shared among a subgroup of MIT folks, or pages that need to be restricted for use by the MIT community only.

The SIPB web server allows one to set up username and password access to a directory in AFS via Apache's basic authentication method. This affords simple username and password access control to web pages stored in AFS lockers, without requiring one to run a personal web server. It also enables one to grant username and password access to folks outside the MIT community who do not have the ability to get MIT web certificates. There are a few very important caveats to using this approach. See the caution about encryption and data security below.

If you plan to use the SIPB web server you will want to review their documentation on how to do this, rather than relying on this page.

A note about support: username and password access via the SIPB web server is NOT a supported service. This information is provided for your benefit, but there is no help available, the service is not guaranteed, and if you use the technology you do so at your own risk. You should NOT deliver mission-critical information or services via this mechanism.

2. The Examples Explained

Section 3 and Section 4 contain examples of setting up certificate-limited and username/password-limited access, respectively. Section 5 shows how to create a simple front-end for the access-limited directories, and explains why this is a good idea. Both examples operate on the same directory, called limited, in my home directory. Substitute your username for mine (othomas) if you want to follow the examples.

The examples below assume you have some basic familiarity with using Athena, creating text files using the Emacs text editor or some other editor of choice, and managing AFS access control lists (ACL's). If you do not, the documents Working on Athena and Emacs on Athena contain excellent summaries of all of these topics.

I am using the word limited rather than secure because there are certain limitations to the security provided by username/password access which render it far less secure than certificate based access. You should be aware of these limitations before you decide whether to use username/password access. See caution about encryption and data security below.

3. Access Control on web.mit.edu via Certificates

A full treatment of setting up certificate-based access control on web.mit.edu can be found at Features provided by web.mit.edu: Limited and secure access to web content via https. Here is an example demonstrating the basic steps:

Create a directory to which you wish to restrict access:
athena% mkdir /mit/othomas/www/limited
Set appropriate AFS ACL's on this directory:
athena% fs sa /mit/othomas/www/limited system:anyuser none
athena% fs sa /mit/othomas/www/limited system:htaccess.mit read
Create a .htaccess.mit file containing appropriate limit instructions for the web server:
athena% emacs /mit/othomas/www/limited/.htaccss.mit
Type the following text in the file:
```
<limit GET>
  require user othomas paco
</limit>
```
You can add different or additional usernames after the require user term in the .htaccess.mit file. Then save the file and exit the editor.

That's it! You can now link to this portion of your site with the URL <https://web.mit.edu/othomas/www/limited/>.

Note that some other features such as limiting access to any valid user (the entire MIT community in the case of web certificates) or a named group of users are also supported. See the document Features provided by web.mit.edu: Limited and secure access to web content via https for a comprehensive treatment.

4. Access Control on stuff.mit.edu via Usernames and Passwords

NEVER USE THE ACCESS-LIMITING METHOD DESCRIBED IN THIS SECTION TO PROTECT MISSION-CRITICAL OR CONFIDENTIAL INFORMATION. IT IS NOT SECURE. See caution about encryption and data security below for more information.

The example below demonstrates how to set up username and password limited access to a called limited in my home directory. The users othomas and paco will be given access.

Create a directory to which you wish to restrict access (skip this step if you completed it in Section 3 and want to use the same directory):
athena% mkdir /mit/othomas/www/limited
Set appropriate AFS ACL's on this directory:
athena% fs sa /mit/othomas/www/limited system:anyuser none
athena% fs sa /mit/othomas/www/limited system:stuff.mit.edu read
system:stuff.mit.edu is an IP ACL. It will allow read access to the machine identifying itself (by IP address) as stuff.mit.edu. See caution about encryption and data security below.
Create a .htpasswd file containing usernames and passwords for this directory:
WARNING: Do NOT use the same passwords you use on other systems. Do NOT use your KERBEROS password. The passwords you put in this file are not secure and can be obtained with little effort by an experienced cracker. See caution about encryption and data security below.
athena% emacs ~/www/limited/.htpasswd
You now need to create an entry in this file for each username/password combination. You can do this in a separate window with:

athena% perl -e 'print "guest:".crypt("throwaway password", "XX"), qq(\n);'

The above command will spit out a line correctly formatted to put into the .htpasswd file, for the user guest. You will need to copy and paste it into your .htpasswd file using a text editor. You can run the command again substiuting other names for guest if you would like multiple passwords for multiple users.
Create a .htaccess file containing appropriate limit instructions for the web server:
emacs ~/www/limited/.htaccess
Type the following text in the file:
```
AuthType Basic
AuthName "Olivers password protected directory"
AuthUserFile /afs/athena.mit.edu/user/o/t/othomas/www/limited/.htpasswd
Require valid-user
```
Note that the .htpasswd file needs to be referenced by its full AFS path. The short form (beginning with /mit/othomas/) will not work. You can find out the full AFS path to a directory by issuing the pwd command in that directory. For a full explanation of what the other fields mean, see Apache's document Authentication, Authorization, and Access Control for a full treatment.

That's it! You can now link to this portion of your site with the URL <http://stuff.mit.edu/afs/athena/user/o/t/othomas/www/limited/>.

5. Creating a Front Page

Since these two methods of limiting access are provided by two different web servers (web.mit.edu and stuff.mit.edu) it is a good idea to set up a front page or portal page to direct visitors to the appropriate links. Something along the lines of:

Welcome to my access-limited site

If you have MIT Personal Certificates, proceed to the access-limited portion of this site
If you were given a username and password to use, proceed to the access-limited portion of this site

If you have problems connecting to the access-limited portion of this site, and think you should be able to, please contact us.

6. Caution About Encryption and Data Security

NEVER USE THE ACCESS-LIMITING METHOD DESCRIBED IN SECTION 4 ABOVE TO PROTECT MISSION-CRITICAL OR CONFIDENTIAL INFORMATION. IT IS NOT SECURE. EVEN THE METHOD IN SECTION 3 USING WEB CERTIFICATES HAS SOME VULNERABILITIES (IP ACL).

You should consider username and password access-limitation to web pages via the SIPB web server a MINOR DETERRENT at best. Information may be protected from being indexed by search engines or from the casual end-user stumbling across the site, but the information will not be protected from a determined cracker. Depending on your threat model this may or may not be acceptable.

Some of the key limitations to know about are:

Username and password information is sent in clear-text across the network. It is not protected by encryption, and is available to anyone listening to network traffic via a packet sniffer or other traffic monitoring software. It is very important to be aware of this limitation. It is also critically important to never use the same password for this site as you are useing for other, more secure, systems. Consider the password you use for this site to be basically available to the public. Since the password travels unencrypted from your computer to the web server, anyone able to sniff traffic on your home network, building network, or your ISP would be able to intercept it.
Access to the AFS directory in which your data is stored is restricted via an IP ACL (available to a machine with a particular IP address, in this case the SIPB or MIT web servers). IP address can faked by knowledgebale individuals, and access to your site obtained that way. While the barrier is higher here, it will not be a deterrent to the determined. This vulnerability affects both the SIPB and MIT web servers.

This page was put together by Oliver Thomas. It is not an official Information Services & Technology document. Last updated 6/2/2005.