David Winkel writes:
>
> 6. "Basic Authentication" and SSL -- Hack basic authentication 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.
We are doing something simliar along these lines in addition to Bob's
S/Ident stuff. We plan to run a secure server (call it A for authentication)
that a web server (call it S) can redirect a client (call it C :-)
to. The connection from C->A will be SSL encrypted, and the user
on C will pass their kerberos username/password SSL encrypted
to A (I know, this sucks, but it works). "A" will use the
username/password to get a TGT, and then it will get a service ticket
for S (ident.S). "A" can optionally encrypt some other data using the
session key in the service ticket, then it base 64 encodes the whole
mess into a cookie which gets sent back to the browser, along with
a redirect to S. C sends the cookie back to S, which decrypts it using
its srvtab, and verifies the identity of the user on C. At that point,
S can create another encrypted cookie (with the principal, client IP,
expiration time) and send it back to C which C will hand back to S
everytime it talks to C.
You can also do other tricks such as encrypting the TGT on A and
sending it back to C. Then, when C contacts A for an S' ticket, A
doesn't need to prompt for a username password again. This has other
implications as well, but does cutdown the number of times a user
will get prompted if they are bouncing around a few web servers.
If you really wanted to, you could even stuff an AFS token into a
cookie (encrypted of course, maybe with a short lifetime).
We are still fleshing out the details and can post something when we
have them worked out.
roland
