Restrict Access to Web Pages with Bluestem

There is 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 approved. All you have to do to use it is set up a configuration file that contains the authorization list.

Configuration File Syntax

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.

Put the allowed.netids file in the web directory that you want to protect. It will protect the directory it is in, and all further subdirectories.

Note: If you have an empty allowed.netids file present, no one will be authorized to access the files in that directory and its subdirectories, because no one is on the approved list. If you have no allowed.netids 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.

The file is divided into sections, for contact, NetIDs, groups and IP addresses. Each section is optional.

Example 1

#My first allowed.netids file.
#Comments start with a # sign.  I love comments.
<a href=""></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.*' won't work.
<allow ip>

<allow NetIDs>

<allow groups>
# See example 2.


  • 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.

The approval process goes like this:

  1. 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.
  2. If the user is not authorized on the basis of IP address, the user must then authenticate to the Bluestem server -- login with their NetID and password --  and https is used for the remainder of the transaction. This is slower, but decent security demands it.
  3. After the user identifies themself with 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.
  4. The file is sent, if authorized. Otherwise, an error message is sent.

Example 2

<a href=""></a>

<allow ip>  ##Allow my desktop machine via IP for speed

<allow groups>


  • The all group 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.
  • Other supported groups include ACCC liaison types (visit the Liaison Manager for more information):
    • GG-liaison-webmaster
    • GG-liaison-pubcontact
    • GG-liaison-proxy
    • GG-liaison-netsec
    • GG-liaison-reach
    • GG-liaison-ecorep
    • GG-liaison-uiso
    • GG-liaison-sysadmin

Example 3

<a href=""></a>

<allow ip>
*    ## allow everyone from campus directly

<allow groups>

Just like example 2, but give everyone on campus direct access without Bluestem login, but require Bluestem login for anyone off-campus.

Example 4

Bluestem is more sophisticated than just dealing with bare NetIDs. A full Bluestem id looks like NetID@domain/authmethod. (If this doesn't make sense, just ignore this section. If you need to know, someone will probably have told you.) This is important only if you want your UIC files visible to some people who authenticate in remote Bluestem domains (as of this writing, UIUC.EDU is the only such remote domain) or if the people use a non-default method of Bluestem authentication.

<a href=""></a>

<allow NetIDs>

<allow NetIDs domain="" >

<allow NetIDs >

<allow groups >


  • 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,,, bob, and Since the files are in the domain, all NetIDs without an explicit domain refer to Note: Do NOT specify 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.

Test and Install

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.

Remaining Caveats: Is it OK that other people on tigger (for or icarus (for can access your files?

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

and your files will be properly secured, locally and on the web.

Last updated: 

September 21, 2016