Wyllys Ingersoll <[EMAIL PROTECTED]> writes: > 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.
Right. > 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. We don't have that documentation available at present. I wish we'd distilled our exploration into a web page at the time. I'd like to hunt up that documentation at some point. I believe that the way that proxy credentials are handled is unique to WebAuth, at least amongst the solutions that we surveyed. I'm sure that S/Ident support is unique to WebAuth, but that's probably not of that much interest to people outside of Stanford (although I must say that S/Ident really is an effective single sign-on solution if you don't have to worry about NAT and other unusual network environments). > 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? WebAuth only uses Kerberos v5 in one particular place, namely the bootstrap for an application server. Note that any authentication protocol could be used here as far as the protocol is concerned; it's just a matter of writing code to handle it. Certainly if someone saw the need for GSSAPI, it's easy to add that. For our application, there didn't seem to be any point in incurring the additional overhead (particularly in terms of network round trips) of GSSAPI. But it's certainly a decision that can be revisited. > Using raw KRB5 protocol means tying one to a particular Kerberos > implementation (MIT, Heimdal, Solaris, Microsoft). Why do you say this? That would indeed be an issue if true, but that isn't our experience elsewhere. We've not tried specifically with WebAuth yet, however, at least so far as I know. My impression is that Kerberos v5 is a standardized protocol and that compatibility bugs are considered exactly that and fixed. Am I being naive about that? > 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. Note that neither does WebAuth, and the choice of Kerberos v5 for that phase of the protocol does not restrict any more than the choice of GSSAPI would. Either way, in order to add another authentication mechanism you have to write more code, and either way the protocol can handle the situation once you've written more code. So I think this is a red herring. > 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 I believe that all of us who are working on cookie-based hacks to authenticate web access would be delighted if client-side support of Kerberos made all of our work obsolete. From past experience with other protocols like e-mail, we're just not holding our breath. Having a protocol in place is one thing. Having a random PC be able to authenticate to web pages without installing additional software is quite another. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
