Wyllys Ingersoll <[EMAIL PROTECTED]> writes: > Writing new code is the barrier that will prevent it from going much > beyond the experimental stage unless it is adopted by a mainstream > browser (mozilla) and web server (apache).
What makes you think that WebAuth hasn't gone beyond the experimental stage? We wrote it because we intended to use it. We've finished it and are actively using it all over Stanford. That's really what we were trying to get out of the project. I hope that it will also be useful to other people, and I'd love for other people to give it a try, but we're already running it in production and intend to keep using it. :) I know there are a lot of experimental web authentication mechanisms out there, but this isn't one of them. We have 189 deployed application servers that are using WebAuth to authenticate users for a wide variety of applications and are using WebAuth to authenticate most of the core web infrastructure on campus (such as our webmail service and restricted content served out of the central campus web servers). www.stanford.edu is running Apache with the WebAuth modules. We're working on migrating our remaining WebAuth v2 servers to WebAuth v3 by this summer. Please bear in mind that Stanford has had a deployed web SSO system using Kerberos for around seven years now. We've been doing this for a long time. WebAuth v3 is a complete rewrite based on lessons learned from our earlier WebAuth v2 system, but we wrote it with a concrete goal of using it for as much of campus web authentication as we possibly could. I know there are also other web SSO systems deployed in production, and I'm not saying that WebAuth is in any way unique. However, it's also not experimental. >> 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? > The protocol is standard, but the programming APIs are not. A site > with MIT libraries will not be able to run apps that compiled against > Heimdal libraries, for example. GSSAPI is a standardized programming > API, code that is properly written will generally compile cleanly > against MIT, Heimdal, and Solaris GSSAPI libraries without modifying > with the code. This is not my experience in maintaining Kerberos software that has to work with both MIT and Heimdal. The GSSAPI implementations are subtlely different and require Autoconf detection to work out the right things to do. I've had to do more porting of GSSAPI code than raw Kerberos v5 code, in fact. I have no experience with Sun Kerberos and know of no one who's using it, so I can't comment there. Running WebAuth on Windows involves a whole host of other issues; this is the most minor by far. See the documentation included with WebAuth on how to get it running on Windows. > Different library directives are needed at link-time, but the code > itself is portable. This is not my experience. I am interested at some point in checking what's required to get WebAuth to build against Heimdal but just haven't gotten around to doing so yet. I have a sneaking suspicion that it's going to be simpler than you're assuming, though. > Not really. With a pluggable GSSAPI library (Solaris, for example), one > does not have to write new code or recompile to add new GSSAPI > mechanisms. Configuring the GSSAPI security mechanisms is done outside > of the code as long as the code uses just the standardized GSSAPI > interfaces. Kerberos v5 is the only GSSAPI authentication mechanism with widespread application use in practice, and every other interesting authentication mechanism that I've heard talked about would require adding a non-GSSAPI protocol anyway. SASL would provide more generality, but I don't see GSSAPI providing a lot of generality right now. > Agreed. However, the systems need to already have Kerberos software > installed and configured in order to even consider using browser SSO, No, they don't. I think you've missed how WebAuth works. It doesn't require any software on the client side whatsoever except for a browser that supports SSL and cookies. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
