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.mitch...@rackspace.com> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
