WebISO: the killer kerberos app?

[kevin mcgowan]

This idea that WebISO can be Kerberos' killer app is right on target.  
We decided that for our purposes placing Kerberos credentials directly 
in the user's cookie database or being forced to modify any web browser 
before the user can participate were both unacceptable.

Cosign <http://weblogin.org/> is in use at several Kerberos and DCE 
schools (notably here at Michigan where it was written), and has indeed 
proven to be something of a killer app for Kerberos here;  departments 
that have never participated in single sign on before are climbing over 
themselves to do so now.

With kx.509, users have the power to never send their Kerberos password 
over the network -- translating desktop single sign-on to the web.  
Cosign uses no domain cookies, allows users to logout of all cosign 
protected services, is capable of transferring Kerberos credentials 
among authorized web servers over an encrypted channel (not in a domain 
cookie or on the query string or in an implicit POST that requires 
javascript), works through firewalls, works across domains, runs on 
Apache 1.3, IIS, Java servlet containers, and has beta support for 
Apache 2.0.  Naturally, all of this software is open source.  Comments, 
suggestions, contributions, gladly accepted.

Kevin McGowan

Christopher Kranz <clk at princeton.edu> writes:

 > I've been looking into a number of WebISO solutions over the last
 > several months.  The one thing that struck me is how Kerberos like a
 > number of the solutions appear to be.  That is, they use a trusted 3rd
 > party with a shared secret and then have a persistent token that 
allows
 > logins without having to re-authenticate for some amount of time.

 > It occurred to me that if you think of the web client as the 
credentials
 > cache Kerberos could easily be used as a WebISO solution.  The web
 > client connects to the web app.  If you don't already have a service
 > ticket you get redirected to a login server that will prompt you for
 > your Kerberos password and get a TGT for you if you do not already 
have
 > one.  So in a sense the web client plus the login server combined 
looks
 > like the traditional Kerberos client.  The login server contacts the 
KDC
 > and gets a TGT and creates a service ticket for the web app.  It ships
 > these back to the web client as cookies.  The web client now has
 > credentials to give to the web app.  If the client connects to another
 > Kerberized web app it is again redirected to the login server but this
 > time it can use the stored TGT to obtain a service ticket for the new
 > web application.