Web Security, Restricted Access, and Bluestem: An Introduction

This page answers general questions about Web security, and lists the ways one can limit access to particular Web pages at UIC.

Security of files on the Web server

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!

Security in transmission - SSL

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:

  1. Encrypts transmissions to prevent eavesdropping (aka "sniffing"). This works in both directions, so that the client can send sensitive information (i.e., password or credit card number) to the server, as well.
  2. Displays a server certificate, signed by a "trusted third-party." This gives the client assurance that he is connected to the proper server, and should prevent (or reduce) impersonation of servers by other rogue servers.
  3. A third thing in version 3.0 is the use of client-side certificates, so that the server can validate the client. But this isn't in widespread use, and there are reasons to prefer other alternatives at UIC at this point.

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

Authentication and Authorization

You need to understand two terms:

  • Authentication - How does the remote server know who you are?
  • Authorization - Given that the server knows who you are, how does it decide to grant access?

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.

IP Restrictions

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

Password Restrictions - Bluestem

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:

  1. Browser contacts server, asks for restricted file.
  2. Server responds with "That's restricted to the xxx realm."
  3. Browser pops up a small window, asks user for id and password relevant to the xxx realm.
  4. User types in id/password, browser repeats request sending id/password.
  5. Server verifies password, checks authorization list, and sends back the file.
  6. Browser caches id/password, so next time this realm is accessed, the user need not type in the id/password again.

Basic Auth is easily available, but has several significant drawbacks:

  • The id/password are usually sent in the clear. (They are encrypted over an SSL link, but SSL is not required for basic auth.)
  • The id/password are not related to any other id/password the user might have. Therefore, they are hard to remember, and there is often no easy way to change them.
  • The id/password are often not stored securely on the server.

Wouldn't it be nice if someone invented a method that would:

  • Use the same id/password of existing computer accounts.
  • Keep the id/password securely, not revealing the password to programmers writing cgi applications.
  • Force encryption of anything worth protecting.
  • Make it clear to the user when it is safe to type in a password.

Well, someone has. Ed Kubaitis, from UIUC, developed the Bluestem protocol to do exactly this. Very briefly, when you use a Bluestem-secured application:

  1. Contact the application. Since you haven't presented credentials yet, you get automatically redirected to the Bluestem ID server. (At UIC, this is ness.uic.edu).
  2. The ID server asks for your NetID and password. (This actually happens in two screens, because it is possible to contact a UIC application, yet use a UIUC password if the application allows it.)
  3. After successful password verification, you get an automatic redirection back to the application, with credentials. The credentials enable the application to know your authenticated NetID, but not your password.
  4. All interactions use SSL, so the password and credentials travel encrypted.

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. 

Last updated: 

September 21, 2016