> Kevin Hildebrand wrote:
>
> /:/project/glue/www/apache/apache_1.2.5/src/mod_auth_umdkrb.c
> (/:/ -> /afs/glue.umd.edu OR /afs/wam.umd.edu)
>
> At any given moment it may not compile - I've added a bunch of stuff
> and haven't tried it out yet.
>
> It's really simple- user types login, password, ticket is obtained and
> created with a random filename. The ticket filename, the username,
> the local and remote IP addresses are then stuffed together and
> encrypted in the server's key (from http srvtab). The resulting block
> is sent to the user as a cookie. On subsequent submits the cookie is
> decrypted providing the username, and the IP addresses are compared to
> verify that the cookie hasn't been tampered with. You could actually
> throw away the ticket file after generating the cookie but I plan to
> use it later for fully authenticated CGI scripts which run as the user
> with tickets and tokens (I already have this working using a different
> method but will integrate it shortly)
>
> Currently the umdkrb module only does authentication and not
> authorization (no hesiod), 'cause I haven't gotten that far yet. (But
> authorization is the easy part!) I'll have that done real soon.
What the University of Michigan actually has in place is somewhat similar,
actually. We've abandoned Dug's Plugin idea for the most part, and are
running with what we had mostly developed before, which is a cookie-based
authentication scheme behind login name and Kerberos password.
But, we are using a cookie that's a random 128 character string, and we
have a daemon that handles mapping the cookie to a username. At this
point we're also not storing ticket files of any sort, as I don't want
access to the web server to automatically compromize anyone who is using
it from a browser, and the cookies only have a lifetime of 4 hours. I
plan to isolate all of the things that require tickets on a separate
server that we can watch more closely for security problems, and can
restrict more thoroughly than the server we're currently running things
that don't require a TGT on.
We've been running this for about 8 months, now in its current
configuration, and it works pretty well. There are several things that
I've got to add to it this month (support for .htaccess directives,
ability to have restricted subtrees of an unrestricted server, etc.), but
it's been fairly heavily used in its current configuration.
I'm not sure if the current version of our code is up in AFS right now,
but if people are really interested in looking at another version...
~~~~
[EMAIL PROTECTED] UofM/ITD Web Services
535 W. William; AA, MI University of Michigan Webmaster
Sony. Because Caucasians are just too damn tall. (Crazy People)
