On Sat, 31 Jan 1998, Douglas Song wrote:
: On Thu, 29 Jan 1998, Ken Hornstein wrote:
:
: > Okay, so let me get this straight -- you run a ssl proxy on your local
: > machine and tell your client to connect to a "fake" POP/IMAP server
: > on your local box, which proxies the connection to the real SPOP/SIMAP
: > server, and you authenticate using plaintext passwords over the
: > encrypted channel? Interesting. Do you have edsll ported to Windows
: > or the Mac?
:
: there are a few commercial SSL client-local proxies, such as SSR or
: SafePassage, that can do this. i don't know of any free versions, though.
: incidentally, this SSL-tunnelling approach is what we're planning to use
: for Kerberized web access (we're scrapping our plug-in work, thankfully) -
: except we're not using passwords, we're adding Kerberos v4 to SSLv3.
:
We have started doing this also. Dug's plugin worked well, but we were
having a hard time selling it to our customers. The extra configuration and
plugin required on the client end was just a bit more work then desired. It
never mattered to me, but I understand the clienteles feelings also.
As I menthioned in a previous post, we are trying to expand our services to
outside und.edu's domain space for Campus restricted applications. We see
this as part of the solution. We are also moving some of our existing
"authenticated" applications to "web based" applications and see this module
as the means for enabling this transition.
Below is a quick note from Kevin on our "mod_auth_umdkrb" module for Apache
and where we are with it. Kevin Hildebrand ([EMAIL PROTECTED]) wrote the
code. I know umich and stanford are working on similar things as well. We
needed to get something done by the start of the semester...
Randall
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.
