At 12:00 PM -0500 3/8/04, [EMAIL PROTECTED] wrote:
Date: Mon, 08 Mar 2004 08:38:05 -0500 From: Wyllys Ingersoll <[EMAIL PROTECTED]> To: Russ Allbery <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: WebISO: the killer kerberos app? Message-ID: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Reply-To: [EMAIL PROTECTED] Message: 2
On Thu, 2004-03-04 at 20:43, Russ Allbery wrote:Christopher Kranz <[EMAIL PROTECTED]> writes:
> 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/>
Isn't this very similar to the what Passport and Project Liberty propose to use? Basically, its a variation of the "secure cookie" scheme. Netegrity does something similar as well.
Is there a comparison anywhere between webauthv3 and the WebISO used by the above mentioned projects? I would be very interested in the comparison, just to know who is doing what, exactly, and what the benefits are for each system.
One thing I dislike about webauth is that it is using raw KRB5 as opposed to the more portable and extensible GSSAPI interface. Why was GSSAPI not chosen? Using raw KRB5 protocol means tying one to a particular Kerberos implementation (MIT, Heimdal, Solaris, Microsoft). GSSAPI is a standard interface and is thus more portable across platforms and does not restrict a site to only using one Kerberos implementation. It also does not restrict one to using Kerberos as the secure authentication protocol.
What about projects that just add support for new authentication methods like the "Auth Negotiate" scheme that Microsoft uses? Work is being done by the Mozilla project to support Kerberos auth via GSSAPI in a compatible manner: http://bugzilla.mozilla.org/show_bug.cgi?id=17578
-- Wyllys Ingersoll <wyllys.ingersoll AT sun DOT com>
------------------------------
Date: Mon, 08 Mar 2004 10:40:26 -0500 From: Sam Hartman <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: Russ Allbery <[EMAIL PROTECTED]> Subject: Re: WebISO: the killer kerberos app? Message-ID: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> (Wyllys Ingersoll's message of "Mon, 08 Mar 2004 08:38:05 -0500") References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 3
"Wyllys" == Wyllys Ingersoll <[EMAIL PROTECTED]> writes:
Wyllys> Isn't this very similar to the what Passport and Project Wyllys> Liberty propose to use? Basically, its a variation of the Wyllys> "secure cookie" scheme. Netegrity does something similar Wyllys> as well.
There's also the free software pubcookie.
My personal recommendation for webauth right now seems to be supporting both gssapi negotiate and pubcookie. I'd prefer a stronger solution than gssapi negotiate. The HTTP SASL draft is being last called, so perhaps we'll get our wish.
-- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
