openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

On Wed, 2012-04-25 at 16:19 -0400, Adam Young wrote:
> Kerberos is designed to solve this problem.  It has the benefit of being 
> integrated into the browser.  Where Kerberos fails is that:  typically 
> it only allows a single authentication provider (KDC in Kerberso speak) 
> and it does not work well with Firewalls. 

Well, Kerberos uses UDP for its network communication, so that's the
place it fails with firewalls.  (Krb4 also embedded the IP in the
ticket, but I don't believe this is required in Krb5; that said, it's
been a long time since I looked at Kerberos.)  Once you have the service
credential (as opposed to the TGT, which you would use to get the
service credential), firewalls are irrelevant to Kerberos.

As for authentication provider…this obviously is not the place to
discuss cross-realm authentication in Kerberos, but rest assured it
works fine.  It requires the realm administrators to set up a trust
relationship, however, which is the disadvantage relative to
certificates.

As far as KDC availability goes—it is incredibly stable; the master KDC
at MIT used to run on an old Ultrix machine, and it ran for so long that
the Ultrix operating system uptime counter rolled over and crashed the
machine.  The KDC is also surprisingly low traffic—it uses UDP, so you
avoid the overhead of TCP (at the expense of having to implement
exponential backoff), and the KDC is only contacted when you need to get
your initial TGT and later the first time you need to contact a
particular service, thanks to the credentials cache.  Finally, it is
very easy to set up redundant slave KDCs.
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>