But what about documents you want to distribute on the Web
but are intended to be viewed only by a restricted audience? Can do. In
fact, there are several ways. But first, you'll need to understand two
Most restricted-access schemes handle authentication and authorization
separately. A big advantage of this approach is that a single authentication scheme
(Bluestem for example; see Password Restrictions below)
can be used for a variety of applications, even when the authorization decisions
are idiosyncratic. To the end user, at least, this makes accessing these secured
systems appear more uniform.
Verification of who you are.
-- Given that the server knows who you are, the decision whether to grant
In general, the user authenticates him- or herself, sometimes
just as a member of a group (e.g. "on campus") or other times as an individual
and then the server can make an authorization decision any way it wants
Return to Contents
Every machine on campus has a network address called an IP (Internet
Protocol) address, and an associated name, often called the Internet domain or
DNS (Domain Name Server) name. The IP address of every machine on the UIC campus
starts with either 128.248. or 131.193. Furthermore, the DNS names
of all machines on the UIC campus end in uic.edu. For example, the domain
name www.uic.edu now corresponds to the IP address 22.214.171.124.
Sometimes it's enough to restrict access to anyone using
a machine on campus (including the dialup 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 ADN network. Restricting
your files to machines that meet IP or DNS name requirements handles this
Note, that IP addresses can change, and DNS names can
change, too, although much more rarely. However, restrictions based on
the uic.edu domain name and these IP addresses will hold for UIC for the
Return to Contents
Password Restrictions -- Bluestem
Sometimes it's necessary to ask the end user for a password,
just so you can let some users in and block others. Most Web servers offer
a variation of what's known as basic authentication:
Basic Auth has several significant drawbacks:
The end user enters a URL or clicks on a link. The browser
contacts the appropriate server.
The server responds with "This file is restricted to the
The browser pops up a small window, asking the user for an
ID and password relevant to the xxx realm.
The user types their ID and password and the browser repeats
the request, sending the ID and password along.
The server verifies the ID and password, checks its authorization
list, and if it checks out, sends back the file.
Meanwhile, the browser caches the ID and password, so next
time this realm is accessed, the user doesn't need to enter their ID and
Wouldn't it be nice if someone would invent a method that
The ID and password are usually sent in the clear. (They
are encrypted if the transaction takes place over an SSL link, but SSL
is not required for basic auth.)
The ID and password are not related to any other ID and password
the user might have, so they're hard to remember and often also hard to
The ID/password tables are often not stored securely on the
Well, someone has. Ed Kubaitis, from UIUC, developed the Bluestem
protocol to do exactly this. Bluestem, and the kerberos system that inspired it,
is explained in a bit more detail in the March/April
1997 issue of ADN Connection.
Use the same ID and password as your existing computer accounts.
Keep the ID and password secure, not revealing the password
to programmers writing CGI applications.
Force the encryption of anything worth protecting.
Make it clear to the user when it was safe to type in a password.
Very briefly, here's how the access to a Bluestem-secured application
looks to the end user:
In particular, this means that you, as a member of the UIC community,
can use your normal ADN netid and tigger/icarus/CMS password to access any Bluestem-enabled
application at UIC, secure in the knowledge that you haven't exposed your password
to any bad guys.
The user enters a URL or clicks on a link to the application;
their browser sends the request to the server indicated in the URL.
- Since the user hasn't presented credentials yet, the browser's
request for service is automatically redirected to the Bluestem ID server.
At UIC, this is ness.uic.edu.
- The Bluestem server -- ness -- sends a request back to the
user for their netid and then for their password. (This is done in two steps
because, if the application allows, you can use a UIUC password when you contact
a UIC application.)
After successful password verification, the browser is automatically
redirected back to the application, with credentials. The credentials include
the user's netid, but not their password.
- Based on the netid, which the Bluestem server has authenticated,
the server decides whether to give the user access to the requested application.
- All interactions between the Bluestem server and the end
user and between the Bluestem server and the application's server use SSL,
so the password and credentials travel over the network in encrypted form.
Return to Contents
Most Web files are transmitted over the network "in the clear"
-- which means that anyone eavesdropping on network traffic anywhere along
the way between the Web server and the browser that requested it could
intercept it. This is not a problem for public documents, but some documents
on the Web are intended for a restricted audience; it wouldn't do if these
documents were intercepted and read this way.
The standard way to combat this is to encrypt the document,
and the most standard type of encryption on the Web is SSL, Secure Sockets
Layer. One of the reasons it's popular is that 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 runs SSL-enabled servers
on tigger and icarus, if you should need them.
SSL does two things:
It encrypts transmissions to prevent eavesdropping (a.k.a.
"sniffing"). This works in both directions, so the client can send sensitive
information (such as passwords or credit card numbers) to the server, as
It 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
Note that SSL does not protect the files while they
reside on the server. Nor does it protect the files once they're downloaded.
It only protects files during transmission. (Similar considerations
apply to any sensitive data sent from browser to server.)
|Never go shopping
on the Web without SSL protection for
at least your credit card information! The URL of SSL-secured transactions
begins with https: (rather than http:), and you'll see an
unbroken key (Netscape) or locked lock (Internet Explorer) in a bottom corner
of your browser.