This page answers general questions about Web security, and lists the ways one can limit access to particular Web pages at UIC.
Your Web files are as safe from tampering as your regular files; any security depends on the usual precautions: set the proper file permissions, and keep your password safe. We also make nightly backups, in case of disaster or in case a malicious hacker gets past our overall security systems.
The main difference with Web files is that you almost always give them public read permission, so that the Web server can read and serve the files. This implicitly gives local users (on tigger and icarus, where the Web servers run) local access, although you normally don't care because you want the public to see your Web files.
Be sure not to give public write permissions to either files or directories!
Some documents need restricted access. Most Web files are transmitted over the network in the clear; not a problem for public documents, but restricted documents could be intercepted and read this way.
The standard way to combat this is to encrypt the document, and the most standard Web encryption is SSL, or Secure Sockets Layer. You don't have to change the document; you just use a SSL-enabled server (and browser) to encrypt on the fly. URLs that involve transmission via SSL start with https: as opposed to the more usual http:
Both www.uic.edu and www2.uic.edu at UIC are SSL-enabled servers.
SSL does two things:
Note that SSL does not protect the files while they reside on the server. Nor does it protect the files once downloaded. It only protects files only during transmission. (Similar considerations apply to any sensitive data sent from browser to server.)
You need to understand two terms:
Most restricted access schemes handle authentication and authorization separately. A big advantage of this approach is that a single authentication scheme (e.g., see Bluestem below) can be used for a large variety of applications, even when the authorization decisions are idiosyncratic. To the end user, at least, the systems will appear more uniform.
In general, the user will authenticate himself (sometimes just as a member of a group, e.g. "on-campus", or other times as an individual), and the server can then make an authorization decision any way it wants to.
Every machine on campus has a network address called an IP (Internet Protocol) address, and an associated name, often called the DNS (Domain Name Server) name. The IP address of every machine on campus starts with either 128.248. or 131.193. Furthermore, the DNS name always ends in .uic.edu For example, www.uic.edu corresponds to 188.8.131.52. IP addresses can change, and DNS names can change (although much more rarely), but the above restrictions will be true for our campus for the foreseeable future (i.e., 2-3 years).
Sometimes it's enough to restrict access to anyone using a machine on campus (including the dialin lines); you might not care exactly who the person is. And, since everyone on campus is welcome to view your files, you don't care about encryption over the net. Restricting your files to machines that meet IP requirements handles this case nicely.
Sometimes it's necessary to ask the user for a password, just so you can let some users in and block others. Most Web servers provide a variation of what's known as basic authentication:
Basic Auth is easily available, but has several significant drawbacks:
Wouldn't it be nice if someone invented a method that would:
Well, someone has. Ed Kubaitis, from UIUC, developed the Bluestem protocol to do exactly this. Very briefly, when you use a Bluestem-secured application:
In particular, this means that you can use your normal NetID and UIC password to access any Bluestem-enabled application at UIC, secure in the knowledge that you haven't exposed your password to any bad guys.
www.uic.edu and www2.uic.edu are Bluestem-enabled, and anyone can use their Bluestem to protect the Web pages they have on those servers.
September 21, 2016