WebISO: the killer kerberos app?

[Russ Allbery]

Wyllys Ingersoll <wyllys.ingersoll at sun.com> 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 (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>