Restricting Access

We have a CGI script, named doc.cgi, whose purpose is to authenticate the end user (either by IP address or Bluestem id), check an authorization list, and supply the Web page if appropriate. All you have to do is set up a configuration file that contains the authorization list. Well, you also have to contact wwwtech@uic.edu so we can force all Web accesses to use this CGI script for all files in your directory tree. Once you do so, you can use the normal URLs for your files, but the accesses will call doc.cgi nonetheless.

(You can actually test doc.cgi with a given config file by making a special URL that calls doc.cgi explicitly. This is fine for testing, but it doesn't provide any protection until we add your directory tree to our list of protected trees.)

To use doc.cgi, you must construct a configuration file. This file:

• Must have the name allowed.netids
• Must have public read permissions (like a Web file).
• Will protect files in the directory where it sits, and all subdirectories. You may have additional, more restrictive files in these subdirectories.

Note: If you have an empty allowed.netids file present, no one will be authorized, since no one is on the list. But if you have no file at all, everyone is authorized, because there is no list.

The configuration file is mostly just a list of allowed netids and IP addresses, with a little bit of structure that helps maintain a large-ish list. But beware that a really big, changing list (such as all members of a given department) will be a pain to maintain. It divides into sections, for contact, netids, groups and IP addresses. Each section is optional.

#My first allowed.netids file.
#Comments start with a # sign.  I love comments.
<contact>
<a href="mailto:wwwtech@uic.edu">wwwtech@uic.edu</a>

# IP addresses can be numbers or names
# If you give a name, it's matched as a suffix.
# If you give a number, it's matched as a prefix; the *'s
#   remind you of this.  
# But you can't match in the middle:  'tigger.*.uic.edu' won't work.
<allow ip>
*.uic.edu
128.248.*

<allow netids>
bobg
john
bob
vinod
adabyron

<allow groups>
# Groups aren't really supported yet. Sort of.

• Each directive or netid or group or IP address goes on a separate line.
• The <contact> info is used when the user successfully authenticates, but is denied access. He or she might want to contact you if the denial was a mistake.
• Once doc.cgi is enforcing security for your files, you may use the usual URLs in referring to your files.
• If you allow access by IP address, the IP restrictions are checked first. If they match, the file is sent immediately, via either http (no encryption) or https (SSL encryption), depending on the original URL. Http is much faster than https.
• If the user is not authorized on the basis of IP address, the user must then authenticate to the Bluestem server, and https is used for the remainder of the transaction. Slower, but decent security demands it.
• After Bluestem authentication, any groups are checked against your list of allowed groups (if any). If that doesn't check, then the netid is checked against the list of allowed netids.
• The file is sent, if authorized. Otherwise, an error message is sent.

<contact>
<a href="mailto:wwwtech@uic.edu">wwwtech@uic.edu</a>

<allow ip>
bobg.cc.uic.edu  ##Allow my desktop machine via IP for speed

<allow groups>
all

• The all group is the only group supported as yet. It means that as long as you can Bluestem-authenticate at UIC, you can access the files. This will let in everyone at UIC, even if they are not on campus at the time.
• I let in a single IP address, so that I could access files more quickly from this machine. Remember, IP-allowed access need not go through the slower SSL protocol. This is useful if I'm the Web developer, and need to view these files often.

<contact>
<a href="mailto:wwwtech@uic.edu">wwwtech@uic.edu</a>

<allow ip>
*.uic.edu    ## allow everyone from campus directly

<allow groups>
all

<contact>
<a href="mailto:wwwtech@uic.edu">wwwtech@uic.edu</a>

<allow netids>
ted
alice

<allow netids domain="uiuc.edu" >
ed
janice

<allow netids >
bob
janet@uiuc.edu

<allow groups >
all@uiuc.edu

• Note that the domain can be specified in the <allow> tag, and will apply to every entry unless overridden. (If you don't specify a domain or auth, then the default will apply.)
• You may have more than one <allow> tag. Actually, you don't have to have any; just list all netids at the beginning of the file.
• The above allowed netids are: ted, alice, ed@uiuc.edu, janice@uiuc.edu, bob, and janet@uiuc.edu. Since the files are in the uic.edu domain, all netids without an explicit domain refer to uic.edu. Note: Do NOT specify uic.edu explicitly; just leave it blank.
• Groups can have domains and authmethods, too. In fact, they must, because who is in what group will depend on the domain and authmethod.

Now that you have made your allowed.netids file, does it work? You can test it without contacting the Computer Center.

Suppose I want to restrict access to all pages located at http://www.uic.edu/depts/accc/private/... I create the allowed.netids file in /usr/local/etc/httpd/htdocs/depts/accc/private and make it publically readable. Then I fire up my favorite Web browser and point it at, say, http://www.uic.edu/htbin/bluestem/doc.cgi/depts/accc/private/index.html (If you're doing this on icarus, of course, you should use http://www2.uic.edu/htbin/bluestem/doc.cgi/...)

This explicitly invokes doc.cgi, and lets me test the various access rules. (Beware that once you log into Bluestem on a given server, your browser will remember your credentials. If you want to test Bluestem by logging in several times, you must reset your browser, either by completely exiting your browser, or by access the URL https://www.uic.edu/htbin/bluestem/logout.cgi This URL works for Bluestem applications on www.uic.edu; a similar URL will be needed for other servers.)

Of course, the above test URL is not convenient for production use, nor does it prevent using the old URL and bypassing the security restrictions. To remedy this, contact wwwtech@uic.edu and tell us which subdirectory tree needs protection. We'll add your directory to a special list known to the Web server. URLs on this list are internally re-mapped by the server so that, for example, any access to http://www.uic.edu/depts/accc/private/index.html is treated internally as if it were actually http://www.uic.edu/htbin/bluestem/doc.cgi/depts/accc/private/index.html (Again, for icarus, you use www2.uic.edu instead of www.uic.edu.)

You're done, except for the caveats in the next section. You can change the allowed.netids file at any time, of course. But if you make a mistake, you might admit too many people. Or too few. If the file does not exist (or is not readable by the web server), everyone is let in. If it does exist but is empty, no one is let in.

Using doc.cgi as described above only provides protection for your files when accessed through the web. It does not protect your files from people who have real accounts on the web server, because these people can just view your files directly.

Perhaps it's ok that anyone on the machine can view the file directly. For example, maybe web access is given to the entire campus anyway. Or maybe you want to limit access to your class, mostly, but it's ok if someone else on campus really wants to view the files. If so, you can skip this section.

If you do care, however, we need to remove public read access from your files, and give explicit read access to the web server. (Normally the web server gets access along with the public. But in this case, that won't work.) Contact wwwtech@uic.edu to set up a special unix group for your files (most departmental sites already have a special unix group) and to add the web server to this group. After that, you can remove public read permissions and restore group read permissions like this:

       chmod o-rx,g+r *.htm*