Kerberos in Browser based Applications

[Richard E. Silverman]

>>>>> "FG" == Frank Gruellich <frank.gruellich at navteq.com> writes:

    FG> Hi, I have set up a Kerberos realm.  A user and a service (let's
    FG> say a database) are both included as principals in KDC database
    FG> and the service restricts access to */dbuser at EXAMPLE.COM.  User
    FG> and service can communicate perfectly using a database CLI at the
    FG> users machine.

    FG> Now these days CLIs aren't "state-of-the-art" anymore and
    FG> $managers refuse to use them.  Let's throw a long discussion and
    FG> platform independent, Web2.0 ready and more buzzwords into the pot
    FG> and we get the need for a browser based web frontend to the
    FG> service.  And that's the point where I do not get the full picture
    FG> about Kerberos.

    FG> How would that work in a fully kerberized environment using all
    FG> these great features like single-sign-on and never transmitting a
    FG> password over the wire?  For sure, I would have to add the
    FG> webserver to the KDC database, but what then?  Would I add the
    FG> webserver principal to the ACL list of the service and add another
    FG> authentication/authorization layer into the web application?
    FG> Could I somehow forward the users ticket for the service to the
    FG> webserver and make the application to give it to the service
    FG> proving this way that the user requested access to the service?

You can do this; it's called credential delegation, and it is supported by
this common Apache module for kerberized HTTP authentication:

http://modauthkerb.sourceforge.net/

But this is just the beginning.  To get it to work, you must convince the
browser to perform the delegation, and this gets a bit complicated.
Firefox has a configuration variable,
network.negotiate-auth.delegation-uris, which controls which URLs are
eligible for delegation.  If Firefox is using GSSAPI (e.g. on Unix or on a
Windows box with MIT Kerberos installed) then that's all you need.  If
it's on Windows and using the native SSPI interface instead, then the
service ticket must have the OK-AS-DELEGATE flag set by the KDC (same
thing with IE).  MIT Kerberos does not support this flag; I had to hack
the code to add support.  The alternative to OK-AS-DELEGATE is to set a
registry bit on the Windows client telling it to blanket delegate to the
entire realm -- not a good idea for two reasons: one, you don't want to
give out your credentials to just anyone, and two, performance.  Normally,
the client goes to the KDC only once for a ticket to the web server, which
it can present without KDC involvement thereafter (until it expires).
With delegation, the browser obtains a delegated TGT *with every page
fetch*.  Even worse, at least in my system, Windows mysteriously issues
two identical TGT requests, taking even longer.

Lest you think this is all rather far-fetched: I do have this working at
my site.  :)

    FG> That would keep all authentication on service side, but is it a
    FG> good idea to give a service ticket to another machine?  Would that
    FG> even work given that the users machine IP# is added to the
    FG> tickets, AFAICS?

With delegation, the client requests a new TGT from the KDC, with the
server's IP address in it.

    FG> In the current setup the software involved are MIT Kerberos, an
    FG> OpenLDAP server as service, e.g. phpLDAPadmin as web application,
    FG> Apache httpd running it, and various browsers used to access it
    FG> running on different OS's.  But I'm more interested in the general
    FG> Kerberos idea how to do that.  However, if you point me to
    FG> specific software I should use in this setup I would be happy,
    FG> too.

    FG> Thanks in advance for some enlightenment.

    FG> Kind regards, -- Navteq (DE) GmbH Frank Gruellich Map24 Systems
    FG> and Networks

    FG> Duesseldorfer Strasse 40a 65760 Eschborn Germany

    FG> Phone: +49 6196 77756-414 Fax: +49 6196 77756-100

    FG> USt-ID-No.: DE 197947163 Managing Directors: Thomas Golob,
    FG> Alexander Wiegand, Hans Pieter Gieszen, Martin Robert Stockman

-- 
  Richard Silverman
  res at qoxp.net