Configure Chromium to authenticate using SPNEGO and Kerberos

Objective

To configure Chromium (or Google Chrome) 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’.

Chromium 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 --auth-server-whitelist option when Chromium is started. This takes as its value a comma-separated list of permitted hostnames. An asterisk can be used as a wildcard. Suitable values in this instance would be www.example.com or *.example.com:

chromium-browser --auth-server-whitelist="www.example.com"

At the time of writing, the HTTP authentication page on the Chromium website stated that the value should be a list of URLs (as opposed to hostnames). This did not appear work when tested.

According to the Chromium issue tracker, SPNEGO support is available from version 6.0.472 onwards. The method described here should be equally applicable to Google Chrome.

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 whitelisted using the option --auth-negotiate-delegate-whitelist (using the same syntax):

chromium-browser --auth-server-whitelist="www.example.com" --auth-negotiate-delegate-whitelist="www.example.com"

As the test results indicate, there are some versions of Chromium that support SPNEGO but do not support delegation.

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 Chromium) which make it unwise to hand over credentials indiscriminately:

• By default, Chromium 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 Chromium does not enable SPNEGO by default, requiring that trusted servers be whitelisted.

Canonicalisation of the hostname can be disabled through use of the --disable-auth-negotiate-cname-lookup option, but that will cause authentication to fail unless the web server has been configured to accept tickets for the relevant service principal.

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 (but unfortunately cannot be enforced by the whitelist).

See also

• Configure Apache to use Kerberos authentication
• Configure Firefox to authenticate using SPNEGO and Kerberos

Further reading

• HTTP authentication, The Chromium Projects
• List of Chromium Command Line Switches, Peter Beverloo

• Conventions
• Privacy
• Legal