WebISO: the killer kerberos app?
kevin mcgowan
clunis at umich.edu
Mon Mar 8 23:48:27 EST 2004
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.
More information about the Kerberos
mailing list