Christopher Kranz <[EMAIL PROTECTED]> 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.
This is exactly the design of Stanford's WebAuth v3. :) See:
<http://webauthv3.stanford.edu/>
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
