LDAP and Kerberos

When most applications used to have user databases/repositories, an effort was made by several companies to create standard ways to centralize user information and details in common places. For the users, this would have meant not needing to remember passwords to access each application anymore.

In the 1980s, telecommunication companies introduced the concept of directory services into IT. A directory service was a central place where all the entities that made up a network were represented and given a name. Directory services were introduced as an Open System Interconnection (OSI) initiative to find common network standards to enable interoperability among different software vendors. This made a standard necessary, and this is one of the reasons why the x.500 directory service came into the world and subsequently the Lightweight Directory Access Protocol (LDAP) as the means to authenticate a user and allow them to access the objects within a directory. The term lightweight in LDAP was introduced to highlight how it differed from the former DAP protocol: LDAP was based on the TCP/IP protocol stack, which highly simplified the access to x.500 directories.

LDAP was great at centralizing information and making it available to end users and applications. However, it wasn’t that great at making collaboration between different directories easy. Having a single directory with all the network users and objects is not easy to achieve, even within the same company. Different business units and areas might have different needs in terms of security and segregation, and they very often do not want to risk that a user without the proper authorization may access restricted and sensitive assets. Luckily, the Massachusetts Institute of Technology (MIT) developed and published the Kerberos v5 protocol in 1993 to protect network services through authentication and authorization of users and applications (versions 1 to 3 were internal to MIT, and version 4 was published in the 1980s).

As an authentication protocol, Kerberos introduced several new innovative concepts:

• SSO: The Kerberos Foundation is about ticket exchange. Successful authentication for either a user or a computer (which is a separate entity) will issue proof of this authentication by an authentication server in the form of a ticket. The authentication server component that oversees the issuing of tickets is known as the ticket-granting server (TGS). An authenticated entity can therefore use this ticket to prove they are who they claim to be and, consequently, request authorization from other entities who trust the same Kerberos authentication server. This process involves other tickets being issued by the TGS – generally, one for each service an entity requests access to. Once, for instance, a user has been authenticated and receives their ticket from the TGS, they can then access different services without being required to insert their credentials each time. They can use their ticket to SSO into other services, so long as the ticket has not expired (in that case, the user must re-enter their credentials).
• Realms and cross-realm authentication: Kerberos also introduced the important concept of realms. A realm is a domain where a Kerberos authentication server is allowed and has the authority to authenticate a user, a service, or a computer. When it comes to a complex organization with different business areas and independent administration requirements, then it is very likely that more than one realm should be put in place. What is the difference from LDAP, then? Kerberos introduced the concept of cross-realm authentication, where a TGS in a realm trusts tickets issued by the TGS in another realm by creating a sort of trust relationship between Kerberos realms. This quite simple concept enabled new use cases that were impossible to achieve before, such as the highly sought-after collaboration between different business unit realms within the same company.

It is worth mentioning that, at the beginning of the new millennium, Microsoft introduced both LDAP and Kerberos as standard authentication protocols in one of its iconic products, Active Directory. Active Directory has been, and it is still today, the foundation of authentication and authorization for most enterprises. But nowadays, its success is also the main IT professionals’ pain in the neck when it comes to shifting that paradigm (which was great in the early 2000s) to a more modern authentication approach.

Everybody remembers that the end of the 1990s was also famous for the advent of a revolution in the IT world. We are talking about the rise of the global internet, known as Web 1.0 – that is, commercial use of the internet on a global scale. This important transition brought with it a higher demand for collaboration between companies where businesses had to interact with other businesses more and more, expanding their horizons on a global scale to avoid being cut off from the great innovation that could overwhelm them in the blink of an eye.

In that era, Kerberos and LDAP could not enable this new type of collaboration; their capabilities were not suitable for making users, services, and computers interact when such services were managed by different legal entities.

The reason why Kerberos wasn’t ideal to be used over the public internet wasn’t related to the security of the protocol but rather to its authentication model, which didn’t easily fit the needs of most public internet applications due to its complexity. Try to imagine the distribution of the keys required by the protocol to all the machines used by end users to access a website. LDAP, on the other hand, would need to import the users of our company into all the LDAP directories of those external organizations that publish a website that we would like to get access to. The larger the number of organizations involved, the greater the complexity of making collaboration work.

It was time for a different way to manage authentication; it was time to introduce the concept of federation.