Hack 14. Work with Single Sign-On Servers

If your web content is hidden behind a security regime, here's how to get through.

This hack explains how to stop Firefox from prompting the user for already supplied login details. In other words, Firefox can be part of a single sign-on environment, where several servers, applications, and/or services share login details. Firefox understands several kinds of server requests for user credentials.

Single sign-on servers are usually found in an Intranet environment. They provide a method of controlling who can access remote servers and the services that they provide, and they can reduce user frustration. Such arrangements are not the same as Secure Socket Layer (SSL). Although SSL and Secure HTTP swap credentials with SSL-enabled servers, those kinds of credentials (digital certificates and digital signatures) are mostly organization-based, not user-based.

The good news is that single sign-on is a no-brainer in Firefox for the simple case. The simple case isn't that much fun, though, so let's explore the subject a bit before we come back to it. Note that special server-oriented configuration files [Hack #29] can also be set up to perform server login actions. In that case, the server is an LDAP server.

2.5.1. The Single Sign-On Technology Jungle

In conceptual terms, single sign-on is a constraint enforced by servers. The server demands special information from the client (for example, a web browser) and refuses to process any request until that information is forthcoming. If a weak security regime (system of identification) is in place, the client might just send operating system login details as plain text to the server. If a strong security regime is in place, the client and server play complicated information games with each other that keep login details secret from everyone.

To understand single sign-on technology in detail requires a great deal of study. This section provides a brief overview only.

2.5.1.1 Locating standards

The first part of sign-on technology involves standards. One technique for sign-on message exchange is to formulate them as HTTP requests and responses. This is the technique that Firefox requires to access secure web servers. Many, many Internet Engineering Task Force Requests For Comment (IETF RFCs) standards cover this subject. They're all available at http://www.ietf.org/rfc/. Here are a few of the critical ones:

RFC 822: Standard for the format of ARPA Internet text messages: This is the granddaddy of all messaging standards, and it's a good place to start if you're not familiar with Internet messaging.
RFC 2616: Hypertext Transfer protocol HTTP/1.1: This standard shows how the core messaging standard is specialized for web messages. It includes the important 401 and 407 return codes, which are returned by a web server that requires a login but hasn't yet received any login information.
RFC 2617: HTTP Authentication: Basic and Digest Access Authentication: This standard adds header fields to the ordinary HTTP standard so that comparisons of user login data between client and server can occur over HTTP. It adds the critical WWW-Authenticate header item, along with a primitive security regime that can use it.
RFC 2743: Generic Security Service Application Programming Interface, Version 2: This standard specifies GSS-API. It's a programming library that wraps around whatever security regimes are available, providing portability. On a given computer, it might provide access to several separate security regimes, such as operating-system login, database login, and smart-card validation. A client like Firefox can use GSS-API to decide what security regimes are supported.
RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism: This standard describes the forward-looking SPNEGO standard. It describes how a client and server can compare via HTTP the security mechanisms that they have available via a GSS-API implementation. It describes how they can agree on which security regime to use.
IETF draft-brezak-spnego-http-04.txt: SPNEGO over HTTP: This standard offers Microsoft's ideas on how SPNEGO and GSS-API should work together.

2.5.1.2 Brand names and standards

The second part of sign-on mixes brand names with standards names:

Kerberos: A high-quality security regime that GSS-API can take advantage of. It's a better quality regime than the ones documented in the previous RFCs, and it requires its own server. Although it's available on Microsoft Windows 2000 and later, it's used mostly on Unix/Linux.
LAN Manager: An ancient Microsoft technology from the days of Windows 95 that provided barely secure LAN access in a way that competed in part with Novell's Netware products.
NTLM: Microsoft's upgrade of LAN Manager for New Technology (NT) versions of Windows (i.e., Windows NT 4, 2000, and XP). It was also back-ported to Windows 95 and 98. NTLM is also the name of NTLM's security regime.
NTLMSSP: NTLM with Security Support Provider (SSP) provides enhancements that removed the need to prompt users every time it's used. It was also back-ported to Windows 95 and 98. NTLMSSP has the same purpose as SPNEGO.
Samba: An open source file and print server for Linux that implements several Windows protocols.
Apache: An open source web server.
Squid: An open source caching web proxy.

Samba, Apache, and Squid all support NTLM and NTLMSSP, so NTLM isn't restricted to Windows.

SSPI: Security Support Provider Interface (SSPI), Microsoft's implementation of a security regime wrapper in the style of GSS-API.

2.5.2. Single Sign-On: The Easy Way

Single sign-on is most commonly used on Windows desktops. Support for this is enabled by default. Using this default setting, Firefox will attempt to silently authenticate the user's Windows domain login against a proxy server. The proxy server used is the default NTLM server for authentication; it can either be a Windows server or Samba, and so on. Firefox's default NLTM behavior is turned on with this preference:

network.automatic-ntlm-auth.allow-proxies /* true = default */

Provided the current proxy server is set up for authentication, there is automatic support for the NTLM security regime in the local network. That regime has weak security, so it is not automatically supported for connecting to servers over public networks. If that kind of connectivity is required, then all such servers must be explicitly identified as trusted. You can create such a whitelist with this preference:

network.automatic-ntlm-auth.trusted-uris  /* default is a null string */

The value for this preference is a comma-separated list of URI fragments. This sample string shows the three legal kinds of fragments:

"https://, http://www.example.com, test.com"

The first fragment says, "Trust all URLs with an https scheme." The second fragment (a full URL) says, "Trust this particular web site." The third fragment is interpreted to mean http://anything.test.com, so any web site that is a subdomain of test.com, including test.com itself, will also be trusted.

There are several potholes to avoid when you use single sign-on with NTLM:

On older Windows boxes running Windows 98 or thereabouts, a Windows patch is required to make everything work. See this Microsoft MSDN knowledge base article for details: "Q266772" (http://kb.microsoft.com). This problem is also discussed in Mozilla's Bugzilla (http://bugzilla.mozilla.org) bug 212336.
Depending on the network setup, users must sometimes remember to quote their username as domain\user. This occurs when domains (workgroups) are not defaulted or matched correctly between client and server. Doing so is somewhat nonintuitive for users. Stick to matching, default domains if you can.
Firefox does not generate Version 2 NTLM responses. It is an implementation that provides just enough support. It does not generate LAN Manager 2 (LM2) or NTLMv2 or NTLM2 responses either. The net effect is that the extra information supplied with those later protocols is ignored.

2.5.3. Single Sign-On: The Hard Way

Very briefly, the hard way to use single sign-on is to guarantee a quality security regime for all sign-on activities. That means using Kerberos. Kerberos is available on all Windows versions from Windows 2000 and later, and on Linux and Macintosh.

Support for SPNEGO is required for Kerberos-based single sign-on. In Firefox, this is turned off by default for two reasons. First, a hostile server could negotiate the browser client into using the NTLM security regime, which is too weak for general Internet use. Second, SPNEGO is open to obscure security attacks when the actual security regime also runs over HTTP. It's possible for a hostile web server to pretend that it serves someone else's domain, in which case it can take over negotiations.

Firefox has two preferences that allow SPNEGO to be turned on. They are whitelists of URIs, in the same format as the NTLM whitelist:

network.negotiate-auth.trusted-uris     /* defaults to empty string */
network.negotiate-auth.delegation-uris  /* defaults to empty string */

The first preference identifies web sites whose SPNEGO messages will be accepted by Firefox. This opens the door to obscure security attacks, so this preference can't be used alone. There are two ways to mitigate that problem. The first is for the browser to ignore requests for HTTP-enabled security regimes, such as NTLM, Basic, and Digest. Currently, that is not implemented, because single sign-on usually occurs in a secure Intranet and those regimes are good enough in that environment. The second mitigation strategy is to use the second preference as well and to carefully control what the web servers send out.

The second preference identifies web sites whose HTTP SPNEGO messages should result in Firefox and the web server delegating the authentication process away from HTTP. This is done using a Kerberos server that acts as a third party. Once SPNEGO starts, Firefox connects, via SSPI or GSS-API, to that Kerberos server. Using the complicated Kerberos protocol, the Kerberos server is told by the Firefox client who the user is. The SPNEGO protocol, which does run over HTTP, then carries some Kerberos information from web client to web server . That is the only time SPNEGO is used. The web server finishes up by checking with the Kerberos server whether authentication was successful. It accepts the reported answer as validation or rejection of the user's identity.

To do all this, set the two whitelists to allow the required web server. That server is then a trusted URI, allowing SPNEGO to go ahead, and it is also identified as Kerberos-enabled. The web server must therefore be a version able to consult a Kerberos server. Then, ensure when configuring the web server that it sends out WWW-Authenticate headers that offer only Kerberos as a security regime. That tells Firefox that Kerberos is the only choice.

Finally, ensure that the Kerberos server is set up correctly for the user population. That means configuring it to be aware of the users that require authentication, as well as ensuring it is exposed to enough of the network to cover all users and all white-listed web servers. Note that some web servers may have an integrated Kerberos server, or they might use operating-system-supplied Kerberos service APIs. In these cases, the Kerberos server might be a virtual server with no separate existence.