> 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:
>
> 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.
A couple of other options:
5. KLP -- A client-side proxy server and a server side cgi-bin handle
authentication between them. It sounds like a cross between Gradient and
CUKerb. The things I don't like about it are the cgi-bin overhead for
every webrequest, and the authentication overhead for every web request.
(For ever web request that goes through the CGI, the script starts up,
gets a token from a srvtab, answers the request, and quits.) This is in
development, and the only reason I mention it is because it was mentioned
by Marcus. It requires a Kerberos implementation on every desktop.
6. "Basic Authentication" and SSL -- Hack basic authentication to
hide behind a secure server, so that all calls are encrypted to and from
the server. Which means that, while the password is passed for every
request, it's passed encrypted with a 40-bit key, or if you're paranoid,
with a 128-bit key in the US. This is supported by Netscape's browser.
I haven't had any time to explore how viable this option is, though I'd
like to.
7. Netscape's API -- Run something under Netscape's cookie model that
lets a user authenticate and get a Netscape cookie, which the browser then
uses to get subsequent pages, until the cookie expires, the browser exits,
or the user explicitly logs out. The server has to keep track of the
cookies and identities, though. Drawback is that it limits you to
Netscape's browsers, and Netscape's server.
I'm sure there are other options that tie into specific servers, too.
~~~~
[EMAIL PROTECTED] | If you're good, you'll be given
UofM/ITD Expert Consultant/Web Master Team | all the work. If you're really
535 W. William, Ann Arbor, MI 48103 | good, you'll get out of it.
