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.


________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to