Like everyone else, we're being pressured to provide access control for Web
pages, images, and scripts, and (like everyone else), we'd like to leverage
our existing infrastructure. We've identified a number of options (see
http://www.brown.edu/Facilities/CIS/ATGTest/Infrastructure/Web_Access_Control/Go
alsOptions.html). Here's a quick summary of what we know about:
1 - We didn't even mention the CUKerb approach, since it requires that very
specific code be inserted into the desktop browsers, and (currently) only
the NCSA style browsers support this option. We have a requirement that our
solution work with off the shelf browsers (read NetScape).
2. Basic authentication, mapped to Kerberos ids and passwords. We rejected
this because plaintext on the wire is unacceptable.
3. SideCar/ S/Ident technology -- (from, respectively, Cornell's Project
Mandarin and Bob Morgan at Stanford). Both of these approaches deal only
with authentication; both work with standard browsers. Here's how they work:
the user requests a URL, the server detects that the requested document,
etc is access controlled, the server opens a TCP conection to the (sidecar,
s/ident) process on the requesting client, the client returns
"authentication info" (eg K4 ticket, K5 ticket, PK stuff, etc), the server
does standard authentication processing on the info returned by the client.
If authenticaiton succeeds, the server then does "site specific
authorization processing" (hopefully, leveraging what you already have).
There are pros and cons to this approach: it works with standard browsers,
it leverages existing infrastructure, it would work with decentralized web
servers run by departments, etc; however, it requires new code in the
server to implement this functionality, new code in all the clients, and
may be susceptible to some forms of attack.
4. Gradient's Web Crusader -- works with standard browsers. It puts a proxy
server in each desktop. For normal URL's, the proxy does the normal,
expected thing. When the proxy recognizes a URL pointing into the DFS
filespace, it uses DCE RPC to connect to a special webserver. The RPC
includes DCE authentication info about the requestor; the server
authenticates, and supports DCE access control mechanisms on the web space.
This approach requires a functioning DCE cell, and the DCE runtime in every
desktop.
This approach looks very interesting, but is completely irrelevant as a
short term solution. (This month, we're deploying DCE -- is everybody
ready?).
There are rumors that Gradient is working on a version of this that removes
the requirement for the DCE runtime in every desktop. That would help
immensely, but (again) not this month (or year, for that matter).
We're currently leaning toward option 3. Even with the down sides, it seems
easy to deploy, could be made to work almost immediately, would seem to
have few negative long term consequences, and is "secure enough" (please
don't flame me on that -- I have to deal in practicalities).
I would be KEENLY interested in comments on these ideas, and in hearing
about other options.
