Configure Firefox to authenticate using SPNEGO and Kerberos
Content |
Tested on |
| Debian (Lenny, Squeeze) |
| Ubuntu (Lucid, Precise) |
Objective
To configure Firefox to authenticate using SPNEGO and Kerberos
Background
Kerberos is an authentication protocol that supports the concept of Single Sign-On (SSO). Having authenticated once at the start of a session, users can access network services throughout a Kerberos realm without authenticating again. For this to work it is necessary to use network protocols that are Kerberos-aware. In the case of HTTP, support for Kerberos is normally provided by the SPNEGO authentication mechanism (Simple and Protected GSS-API Negotiation), also known as ‘integrated authentication’ or ‘negotiate authentication’.
Firefox supports SPNEGO, but it is disabled by default for security reasons.
Scenario
Suppose you wish to authenticate to the web site http://www.example.com/ using Kerberos. The web server has been configured to accept Kerberos tickets from the realm EXAMPLE.COM. The user running the web browser has a ticket-granting ticket for that realm.
Method
To enable SPNEGO, the URL in question must be whitelisted using the Firefox configuration setting network.negotiate-auth.trusted-uris. This takes as its value a comma-separated list of URL prefixes and/or domain names. Suitable values in this instance would be www.example.com or http://www.example.com/.
To change the setting:
- Navigate to the URL
about:config. - Click past the warning of harmful consequences.
- Type
negotiate-authinto the filter at the top of the page, in order to remove most of the irrelevant settings from the list. - Double-click on
network.negotiate-auth.trusted-uris. A dialogue box for editing the value should appear. - Enter the required hostname(s) and/or URL prefix(es) then click OK.
Variations
Enabling delegation
Delegation is a feature of Kerberos where you allow a network service to authenticate to other network services on your behalf. This is done by giving the first network service a delegated copy of your ticket-granting ticket.
For example, consider a webmail server that acts as a front-end to an IMAP server. One way to implement this would be to provide the webmail server with a master password that can access any account. With delegation that is not necessary because the webmail server can use the ticket-granting ticket supplied by each user to access the corresponding IMAP account.
Delegation by its nature requires a very high level of trust in the network service that will receive the ticket-granting ticket. For this reason, whitelisting a server using the method describe above does not by itself cause delegation to be enabled. To do that it must also be added to network.negotiate-auth.delegation-uris (which uses the same syntax).
Security considerations
Without delegation
In general it should not be necessary to trust a service in order to authenticate to it using Kerberos, however there are two features of SPNEGO (and its implementation by Firefox) which make it unwise to hand over credentials indiscriminately:
- Firefox canonicalises the hostname of the web site before obtaining the service ticket. This makes it possible for a malicious web server to request credentials for a web site that it does not host.
- Kerberos provides the client and the server with a session key that, when used properly, can be used to guard against misuse of credentials by an intermediary. The SPNEGO protocol does not use this session key (and in the absence of TLS or SSL, provides no protection at all for the session content).
A further consideration is that SPNEGO and GSSAPI can support authentication mechanisms other than Kerberos (including highly insecure ones such as Microsoft NTLM). It is for these reasons that Firefox does not enable SPNEGO by default, requiring that trusted servers be whitelisted.
The security of SPNEGO can be greatly improved by using it in combination with TLS or SSL, as that makes it significantly more difficult for a third party to take control of the channel once authentication has taken place.
With delegation
From a security perspective delegation is a mixed blessing. If a server is compromised then the damage is limited to users who access it during the affected time period, but unless you take specific precautions to limit what their delegated ticket-granting tickets can be used for then the consequences for those users could be significantly more severe.
For this reason you should only delegate to individual web sites in which you have a high level of trust, and which have a clear need to use other services on your behalf. The use of TLS or SSL is strongly recommended and should preferably be required by the whitelist entry.
See also
- Configure Apache to use Kerberos authentication
- Configure Chromium to authenticate using SPNEGO and Kerberos
Further reading
- Integrated Authentication, Mozilla Developer Network