Restricting Access

We have a Web service 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.

To use this service, 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.
• You may use the usual URLs in referring to your files when this service is protecting 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? All you have to do is put the allowed.netids file in the directory you want to protect and try it out.

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 this service 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*