What do I need to know about web security, restricted access, and Bluestem?
This article addresses general web security questions and how to restrict access to websites using Bluestem 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.
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:
SSL does two things:
- 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.
- 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.
- 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.)
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.
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. 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:
- Browser contacts server, asks for restricted file.
- Server responds with "That's restricted to the xxx realm."
- Browser pops up a small window, asks user for id and password relevant to the xxx realm.
- User types in id/password, browser repeats request sending id/password.
- Server verifies password, checks authorization list, and sends back the file.
- 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:
- Contact the application. Since you haven't presented credentials yet, you get automatically redirected to the Bluestem ID server. (At UIC, this is login.uic.edu).
- 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.)
- 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.
- 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.
webhost.uic.edu and people.uic.edu are Bluestem-enabled, and anyone can use their Bluestem to protect the Web pages they have on those servers. Virtual Servers may also have Bluestem enabled at no cost.