Single Sign-On Using Mod_Auth_Tkt

One of the most discussed concepts about authentication today is the concept of Single Sign-On, or SSO. SSO is the ability for a user to log into one location, and authenticate across several domains without entering any additional credentials. This saves the user from having to enter several credentials for related websites, as well as possibly prevent the user from having to remember multiple logins.

While developing the Rolling Stone and Vogue Archives, we needed a SSO system that could integrate our ASP.Net based archive with each provider’s existing authentication systems, primarily Apache-based web applications. Our solution was to develop a C# implementation of mod_auth_tkt cookie-and-token based authentication system, which we have since released open source.

Creating a C# implementation of mod_auth_tkt allowed us to use an IIS-hosted ASP.Net website as a mod_auth_tkt SSO endpoint, eliminating the need to handle login on our application side. Instead, we could redirect all logins to a single login page on the provider’s website, removing the security burden of having multiple login endpoints.

Mod_auth_tkt’s custom userData also allows us to read a subscription level from the cookie itself, and treat the user accordingly. Without the need to access Vogue’s internal database, we are able to securely transfer this information through the client side by validating the mod_auth_tkt hash.

History of Mod_Auth_Tkt

Mod_auth_tkt was originally written and released by Raimondas Kiveris, a software engineer working for GlobalWorks. Soon after the project was released under the Apache license, Gavin Carr of Open Fusion took over administration of the project and released mod_auth_tkt version 2.0 in February of 2005.

The original version of mod_auth_tkt, version 1.3, was written specifically for the Apache web server as a secure way to track an authenticated user, especially across web farms. It provided a secure way of keeping track of an authenticated user for Apache, by using an md5 hash to validate the user’s authentication cookie. The hash would validate both a userId, as well as a single text data field, although the cookie was also able to store other token data.

Version 2.0 was created to address a vulnerability with the 1.3 version of mod_auth_tkt. In version 1.3, any tokens set in the mod_auth_tkt cookie were not included in the hash, allowing unscrupulous users to change the data. In version 2.0, all tokens are also hashed, preventing users from changing the token data.

Inner Workings

Mod_auth_tkt provides a cookie-based single sign-on that is compatible with any language that has an implementation built.

Mod_auth_tkt provides a cookie-based single sign-on that is compatible with any language that has an implementation built. Because of the nature of the token, the token can be validated by any server with a correct secret key, allowing many discrete systems to use the same token for validation. For example, two systems running Apache and ASP.NET can share a token to authenticate a user across systems.

Mod_auth_tkt works by using a hash, usually MD5, of the user’s information salted with a secret key, IP address, and timestamp. The salt, user’s id, tokens, and userdata will be concatenated together, and then hashed to create a digest which is prepended to the plain text cookie data. When a remote server receives the cookie, the server only needs to hash the plain text data, and verify that the computed digest is equal to the digest in the cookie. This ensures the user is unable to modify the cookie without invalidating the cookie’s digest.

Nonetheless, like most technologies, mod_auth_tkt also has its own set of hurdles. In HTML, cookies are domain-specific, which presents a challenge when authenticating a user on a separate domain. To get around this, the token can be passed across domains using a HTTP POST call when redirecting from one server to another. Additionally, since mod_auth_tkt is primarily a cookie-based authentication, many implementations of mod_auth_tkt will not work on systems where cookies are disabled.

Conclusion

Mod_auth_tkt was a useful tool for implementing SSO with the Rolling Stone and Vogue Archives. Authentication using mod_auth_tkt lets us securely authenticate while keeping the login on the provider side, and keeps the user from having to log in twice.

For more information about mod_auth_tkt, take a look at our sample C# implementation on GitHub.

(Photo credit: Kathleen Franklin via Flickr)

About David Benson

David Benson is a software craftsman in the Dayton, Ohio area. He specializes in Javascript and ASP.Net development. In his free time, David enjoys building computers, reading, and fiddling with jQuery, KnockoutJS, and Python.

  • Another potential hurdle worth noting.  While using the IP address as a validation control, quite often a user’s IP address will differ depending on where they are surfing to – this is especially common in corporate environments.  That is – a user may present a different IP addresses to different servers depending on where the servers are located.  In this case an acceptable solution may be to configure mod_auth to not use IP addresses: this obviously needs to be coordinated between the participating servers.

  • It should be mentioned that the hard work of porting mod_auth_tkt to C# and working with our integration partners to get everything coordinated and working was done by Robin Kaye of AIS.  David has since taken over the task of maintaining and extending the codebase as needed for ongoing integrations.

  • Robin Kaye

    This is an excellent explanation of the topic.  Nicely done!