Firefox Hacks [Electronic resources] نسخه متنی

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.

h5

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.