Topics Map > Security
Topics Map > Communication & Collaboration > Website Services
How do I restrict access to web pages with Bluestem?
This article details how to restrict access to web pages using 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.
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.
#My first allowed.netids file. #Comments start with a # sign. I love comments. <contact> <a href="mailto:email@example.com">firstname.lastname@example.org</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> # 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:
- 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 -- login with their NetID and password -- and https is used for the remainder of the transaction. This is slower, but decent security demands it.
- 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.
- The file is sent, if authorized. Otherwise, an error message is sent.
<contact> <a href="mailto:email@example.com">firstname.lastname@example.org</a> <allow ip> bobg.cc.uic.edu ##Allow my desktop machine via IP for speed <allow groups> all
- 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):
<contact> <a href="mailto:email@example.com">firstname.lastname@example.org</a> <allow ip> *.uic.edu ## allow everyone from campus directly <allow groups> all
Just like example 2, but give everyone on campus direct access without Bluestem login, but require Bluestem login for anyone off-campus.
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.
<contact> <a href="mailto:email@example.com">firstname.lastname@example.org</a> <allow NetIDs> ted alice <allow NetIDs domain="uiuc.edu" > ed janice <allow NetIDs > bob email@example.com <allow groups > firstname.lastname@example.org
- 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, email@example.com, firstname.lastname@example.org, bob, and email@example.com. 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.