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 JungleIn 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.
2.5.1.1 Locating standardsThe 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:
2.5.1.2 Brand names and standardsThe second part of sign-on mixes brand names with standards names:
2.5.2. Single Sign-On: The Easy WaySingle 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:
2.5.3. Single Sign-On: The Hard WayVery 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. |