Authentication, Single Sign-On and Federation

Basic password authentication

All operating systems and well-coded application programs do not store their users' passwords in their user directories. Rather, they run each password through a formula that produces a "hash" value that cannot be reversed which is stored instead. When an individual signs into a system, he or she usually is asked to provide a user ID (a.k.a. user name) and an associated password. Simple application systems will typically send the password (hopefully in an encrypted form) to the target system that will calculate the "hash" value of the password and compare it to the password hash that it holds in its user table. Password hashing should be a "one-way" function, i.e., you should not be able to derive the clear text password value by applying some formula to the hash. One-way password hashing is far more effective in protecting user passwords than encrypting the passwords on file with a common key. When you use a common key to encrypt all passwords on file, you render them all vulnerable to being discovered by anyone with access to the password store who could derive or learn the common key value.

Since a one-way password hash cannot be reversed, even a person who can gain access to a computer's password hash store cannot determine a good password's value by examining its hash. We stress the word "good" in the previous sentence for a reason. Weak passwords can be easily cracked using tools that are readily available on the Internet. For information about the tools and methods that are used to crack passwords, please visit the Password Attacks and Countermeasures page.

Multi-factor authentication

In cases where additional authentication security is required, organizations often authenticate using two or more of the following factors:

• What you know, e.g., a password, passphrase or PIN
• What you have, e.g., a card, a token, a special personally identifiable electronic file called a "certificate"
• What you are, e.g., a fingerprint, a retina scan pattern, a voice print, a hand print, writing pressure, etc.

Often, the "what you are" factor can be expensive to implement, so many organizations have relied on the "what you have" factor along with a password to achieve their multi-factor goals.

Multi-factor authentication has been available for decades, primary through the use of smart-tokens. A smart-token is usually a device (key fob, card, smart phone app) that displays a number that changes every minute. When you use a smart token to log in, instead of submitting a password alone with your user name, you enter your user name, your PIN (what you know) and the current number that is displayed on the token (what you have) to authenticate.

Newer multi-factor techniques use your mobile phone as your "what you have" factor. With this technique, you prove you have your phone by responding to a prompt with a number that is texted to you by the authentication service after you have entered your password.

A certificate is a file that identifies you through cryptography that you must unlock by entering the certificate's password or passphrase when prompted. The "unlocked" encryption keys in the certificate information prove that you have the certificate in your possession.

Single sign-on

In a nutshell, single sign-on is any mechanism that allows a user to log in once to get access to many applications. In a standalone Windows environment, logging into Windows can often mean you can use all of the applications on the system without having to log in multiple times. Even in cases where Windows domain users access applications that are part of a single domain or group of "trusted" domains, additional logins are often not necessary.

However, if you are accessing applications across multiple systems and domains, e.g., web sites, applications running on other operating systems, applications run by other organizations, the number of logins you are required to perform can become irritating.

Many single sign-on implementations used by Web applications use a central authentication service like those described below. These mechanisms rely on a very simple paradigm: If you log in successfully, you get a ticket. If you have a valid, unexpired ticket, you can use any participating application without logging in. For web applications, a single sign-on ticket is basically a web cookie that usually has an expiration date and time specified.

Note: Even today, single sign-on across web applications is not an exact science. Many organizations wrestle with decisions about what signing off from a single application means. Does it mean you have signed off all of the applications or just one? After all, to be allowed to access the other non-signed-off applications, the user must still have a valid ticket, so shouldn't that ticket give the user instant access to the application that he or she just had logged off?

Central authentication and federation services

Kerberos

One of the weaknesses of basic authentication, which is used by most web and client-server applications is that the password travels across the network - hopefully in an encrypted message packet - but there are many applications spanning the globe where the URL of a web login page starts with "http:" (i.e., the page is not encrypted!).

Kerberos, developed by the Massachusetts Institute of Technology, included a mechanism that did not involve the password being transmitted at all. Rather, the user initiates the login process by sending a service request message packet with the user's ID to the target system. The target system then creates two messages, a session key and a "ticket-granting-ticket" or "T-G-T", encrypts the two messages with the user's password hash as an encryption key, and sends the messages back to the user. The user's system generates a password hash from the password that was entered by the user, and uses the hash to decrypt the two messages that were returned by the target system. If the user entered his or her password correctly, then the messages will be decrypted to yield the proper session key and T-G-T information. That information can then be used to complete the logon. If the user-entered password is incorrect, the decryption will fail and the user will not be able to access the system.

Note: Microsoft Windows authentication uses a form of Kerberos.

Remote Authentication Dial-In User Service (RADIUS)

RADIUS is a system that provides centralized authentication, authorization and accounting ("AAA") functionality to application programs and system services. Originally developed to provide AAA services for dial-up applications, RADIUS has vastly expanded its scope and may be used to provide AAA services to any application that has been developed to integrate with it.

The benefit of RADIUS is that it provides a common authentication method across all of the applications that use it. From a security-standpoint, this has the benefit of allowing us to validate the integrity of the authentication code of all application that use RADIUS by simply validating RADIUS itself.

Central Authentication Service (CAS)

The Central Authentication Service of "CAS" is an authentication method for web applications that was developed at Yale University to provide web developers with an authentication "black box" so they no longer needed to add authentication program code into their web applications.

When a user needs to authenticate to a web application using CAS, he or she enters the URL of the target web site into his or her browser. The web site immediately redirects him or her to the central login page managed by CAS. CAS can be used against any directory system that uses the Lightweight Directory Access Protocol (LDAP) to authenticate the user. CAS will notify the web site regarding the success or failure of the user authentication process and the user ID of the individual who attempted to log on or who was successful in doing so. If successful, the web application can proceed as it would if it had authenticated the user itself.

As for applications using RADIUS, the integrity of the authentication process for web applications using CAS can be verified by simply validating the CAS code itself.

Federation, Shibboleth and SAML

On occasion, organizations need to allow individuals from other organizations to access their applications. Using traditional methods, that would mean that the organization offering the service must maintain a set of user names and passwords for individuals from any organization wanting to use the service, along with everything that implies, e.g., password resets, keeping identities up to date, removing users who have left their organizations from the group of authorized users.

To address this, the concept of a federated identity was developed where each organization trusts the other organizations in a federated group to authenticate their own user base. For example, if UH Clear Lake wanted to access a system at UH Victoria and we were part of a federated group, a user at UH Clear Lake would log in through UH Clear Lake's authentication servers and the application at UH Victoria would trust that the user was legitimately authenticated as long as UHCL issues the user a valid ticket. Using this approach, users at UH Clear Lake could change or reset their passwords without any UH Victoria system involvement. Additionally, if a user leaves UH Clear Lake, the disabling of his or her UH Clear Lake user name would also disable his or her ability to access the UH Victoria system.

Federation also provides functionality that allows the target application to obtain certain relevant pieces of information about the user who is logging on. In the above example, if UH Victoria is providing a service that should only be available to faculty, the federation process could allow UH Victoria to obtain the directory attribute from UH Clear Lake that would indicate whether or not the authenticated user has a faculty affiliation with the University.

Today, most forms of federation utilize a protocol based upon the Security Assertion Markup Language (SAML). One SAML-based implementation that is commonly used by higher education is called "Shibboleth". When developing a web application using Shibboleth federation, you interact with the Shibboleth service on your campus much the same as you would if you were implementing CAS - by redirecting the user to the Shibboleth service and having Shibboleth redirect back to your application along with the status of the user interaction AND (unlike CAS) certain user attributes the application needs to properly grant access to the user.

Note: Shibboleth is a federation system, not an authentication system, so it must be integrated with whatever local authentication service that you want to use, e.g., CAS, Active Directory.

Federating across many organizations

In the above example, the interaction between two organizations does not require any additional external services to assist with the federation process. All that is needed is to set up the trust between the two campuses and point each campus to the other campus' federation and authentication service. But what if an organization is offering a service to dozens of other organizations and also consumes the federated services of dozens of other organizations? The effort of maintaining a number of point-to-point relationships can be daunting as the number grows.

To address this issue, organizations that have a common interest join a federation that, as a central entity, manages the trust among its participants. A widely accepted higher education federation is InCommon.

When an organization is part of a federation, "Shibbolized" applications need to only redirect to the federation's central service when authenticating users and authorizing their access. The federation's central organization will present the user with a dropdown box with the names of all of the member organizations. The user then picks his or her organization from the list and is redirected to his or her federation and authentication service. The status of the authentication and any authorized user attributes are then passed via the central organization to the application server.