>>>>> "FG" == Frank Gruellich <frank.gruell...@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 */dbu...@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 r...@qoxp.net ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos