0

When comparing Kerberos to SAML, a common argument on StackOverflow sites and the rest of Internet is that SAML is for Internet / cloud applications while Kerberos is for enterprise LAN. There are several claims to support such an argument:

  • Kerberos requires client and service to be domain joined.

    However, from my understanding:

    1. Kerberos requires trust between client and KDC, as well as service and KDC
    2. Domain-join is just one way to establish the trust in an AD environment. There should be other ways (e.g. manual configuration). The protocol does not mandate domain-join.
    3. On the other hand, to use SAML, the IdP and SP must be configured to trust each other as well.

  • Kerberos requires client to have direct access to KDC

    However, from my understanding:

    1. It is true that again, in an AD environment, the KDC (domain controller) is not usually exposed to the Internet.
    2. But generally it is safe to make a KDC publicly accessible (provided other security measures) because Kerberos was designed to operate in untrusted networks.

  • Kerberos has strict requirement on clock synchronization

    However, from my understanding:

    1. Most machines have access to NTP / Internet if they need to sign into cloud apps
    2. The protocol now is able to handle clock out of sync
    3. SAML (TLS) has requirement on clock as well (although less strict)

In addition to those seemingly invalid arguments to me, there is software (e.g. ADFS) that acts as an adapter between Kerberos and SAML. So my question is, why don't we just use Kerberos for SSO into cloud apps (like Salesforce)? Why was SAML invented to address what problem Kerberos has?

Ryan
  • 177
  • 1
  • 7
  • 3
    AFAIK Kerberos requires configuration of the client, while only SAML requires only server-side configuration. - The fact that SAML is a web based protocol makes it a lot easier to use over the internet at large, where still a lot of (enterprise) users don't have direct internet access but are required to use web proxies. – Bob Apr 11 '21 at 14:22
  • 1
    Federating is simple and secure. It provides a narrow slice of what is needed, without the baggage and risk of a service provider setting up forest/domain to trust customer forests and the associated direct network connectivity. Also, `Kerberos was designed to operate in untrusted networks`, a lot has been learned about Kerberos in the eight years since that question/answer. – Greg Askew Apr 11 '21 at 14:39
  • Ok, simplicity & ease of use seem to be the consensus here. @Bob mind explaining more how the use of web proxy is relevant in this case? – Ryan Apr 11 '21 at 14:50
  • 1
    @GregAskew what are those "a lot"s that were learned about Kerberos recently? – Ryan Apr 11 '21 at 14:51
  • 1
    Most enterprise users don't have direct internet access and Kerberos requires UDP port 88 to connect to kerberos authentication , limiting their authentication capabilities to a Kerberos server outside of their corporate network – Bob Apr 12 '21 at 06:43
  • @Bob: Kerberos doesn't require _much_ configuration (only the KDC addresses, and those can be retrieved from SRV and URI records)... and it has an official way of being tunnelled over HTTPS itself (MS-KKDCP), so that's not really a problem anymore. – user1686 Apr 14 '21 at 16:46

0 Answers0