Capturing the history of Cornell's authentication tools began when Chief Information Security Officer Bobby Edamala remarked that upon arriving in Ithaca, he discovered five or six authentication methods in use across the campus. 

Orientation

Pete Bosanko and Jerry Shipman, familiar with many or all of the approaches, kick off this history with the following definitions: 

• MIT Kerberos - the original authentication system.
• Sidecar - the back door to a legacy desktop-based Kerberos login system.
• CUWebAuth - a web based login system for web applications to tie into Kerberos or AD/Kerberos. 
• Active Directory (AD) - a Lightweight Directory Access Protocol (LDAP) directory with Kerberos authentication combined, so it is partially an authentication system. 
• Azure - Cloud version of Active Directory, actually uses Active Directory under the covers. 
• ADFS - is not an authentication system at all, it was used to move account information from Active Directory to Azure. The new product is called Entra Connect. 
• Shibboleth - a higher-education community Security Assertion Markup Language (SAML) implementation for federated login.

Kerberos, Mandarin, and NetIDs

According to John Rudan’s History of Computing at Cornell (2005, p. 180), Kerberos was the university's first authentication method. An open-source solution created at MIT, Kerberos was implemented at Cornell in the 1990s as a network authentication protocol designed to enable community members and services to prove who they are in a secure way, even if they are not on a trusted network.

Cornell's Kerberos infrastructure began in 1994 as part of Project Mandarin, a consortium effort partially funded by an Apple grant. The initial deployment ran Kerberos v4 on a pair of AIX servers named Mutt and Jeff, housed in the CCC datacenter with 8mm tape backups attached. This was before Windows 95 and Active Directory existed.

The project stood up Cornell's first enterprise LDAP directory and the infrastructure enabled early self-service applications, including campus kiosks where students could look up grades and retrieve unofficial transcripts.

Kerberos authentication also supported Linux authentication for research systems and the new NetID system (Rudan, 2005, p. 209), still in use today.

As industry practices evolved, migration toward Active Directory began around 2009, with services gradually moving over the following years. The final Kerberos decommissioning was completed in 2025, retiring a system that had served the institution for over 30 years, supported more than 630,000 authentication principals, and provided SSO for over 8,000 web services -- apparently without any major security or availability incidents, and with minimal operational overhead.

Sidecar

Kerberos, a non-web authentication method, works well for desktop logins, UNIX systems, servers, and secure internal services. It does not natively support web browsers.

As websites and web services began to evolve, Cornell community members needed to access restricted sites with their Kerberos passwords. 

To extend the Kerberos password security for web services, CIT's Identity Management team developed Sidecar, a desktop application installed on user's computers to handle Kerberos logins and pass safe tokens to the restricted websites.

For the websites, an Apache web server module on each protected server to talk to Sidecar using a custom protocol, CUSSP.

Finally, Cornell built an authorization server, Permit, to check whether a logged-in community member was allowed to access a specific page, action, or resource.

Predating Shibboleth and other modern Single Sign-On technologies, these three components were providing web authentication at Cornell.

When Kerberos migrated from version K4 to K5 in 2007, Sidecar did not make the transition. The migration team determined the Sidecar architecture and the proliferation of Network Address Translation (NATs) showed a similar solution for K5 would not have acceptable functionality or security. Kerberos Viewer replaced Sidecar in January 2008. The Identity Management Team also significantly enhanced CUWebAuth with the new K5 release, creating CUWebAuth 2.0.

CUWebAuth and CUWebLogin

According to team documentation created in 2007 by Greg Roth, the Cornell University Web Authentication (shortened to CUWebAuth) infrastructure was designed in 1999 as a side solution for use in a small community of users unable to use Sidecar—including devices sharing a public IP address through NATs.

CUWebAuth is a web server filter (software extension) that enables the extended web server to integrate with campus authentication and authorization systems. CUWebAuth is used to protect specific pages and other resources on such a web site.

The first time a user attempts to access a restricted page on a protected website, the community member must first login in order to obtain a site cookie. Individual web servers should not handle the community member's Kerberos password long term so the login process is supported by the CUWebLogin service.

The early CUWebAuth and CUWebLogin system was built around Kerberos, but in a non-standard and complex way.

CUWebAuth Vulnerability Detected by Student

Now a Google Staff Engineer, Greg Roth demonstrated a serious vulnerability—a design flaw—in CUWebAuth while still a Computer Science student at Cornell. 

In 2005, the recently graduated Roth joined the CIT Identity Management Team. Roth and two of his colleagues, Hong Ye and Pete Bosanko, redesigned and reimplemented CUWebAuth. The new implementation remained in operation for almost 20 years.

Pete Bosanko's CUWebAuth Technical Presentation, circa 2005, captures a snapshot of their work.

CUWebLogin Now

No longer affiliated with CUWebAuth, the current CUWebLogin continues providing secure access to restricted Cornell websites and web services. In 2025, the web form was configured to accept NetIDs, CWIDs and GuestIDs.

Active Directory

Cornell began adopting Active Directory in the mid-2000s, primarily to support Microsoft Exchange and a growing demand for mobile email. By 2009, AD was part of the university's core identity architecture.

Active Directory uses Kerberos and NTLM, a Microsoft authentication protocol. As early as 2009, CIT identified the duplication of infrastructure (between MIT Kerberos and Active Directory) as a challenge on the horizon.

Active Directory Federation Services (ADFS)

Microsoft's on-premise token service sits on top of AD to enable community members with AD credentials to sign into external or cloud applications. 

Azure Auth Evolves into Entra ID

Microsoft supplemented their on-premise authentication solutions with a cloud-native Identity-as-a-service platform system, Azure Auth. This solution is now called Entra ID.

Legacy Authentication Methods Retired

Read Quiet Success: Retiring Authentication Technical Debt at Cornell for details about how three different solutions were retired in six years.