Introduction

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 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: UIC does run SSL-enabled servers on tigger and icarus, if you should need them.

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

An article in The A3C Connection discusses encryption techniques, and SSL in particular. This article is at the 30,000 ft level, but there are a zillion pages on the Web with more details.

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?

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

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

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.