Chrome and SPNEGO

Update, Aug 2015: The landscape on OS X has changed several times since this post was written. Chrome on the Mac now fully supports the “defaults” mechanism to set policy defaults. Chrome on Linux gained a proper managed configuration, which we use locally (I produced the lcfg-chrome component for this purpose).

Quick guide to configuring SPNEGO on the Mac:


$ defaults write com.google.Chrome AuthServerWhitelist <cosign.server.tld>
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist <cosign.server.tld>

Restart Chrome and rejoice. What follows is probably only of historical interest…


I was most impressed by the efficient conclusion to the enhancement request for SPNEGO on Chrome, but having read that the request had been met, I struggled for far too long to discover how to activate it.

Irritated by Firefox 4 beta 7’s breakage of SPNEGO on the Mac*, but reluctant to revert 3.6, I felt it was time to reinvestigate the alleged Chrome support (note, you can restore SPNEGO to beta 7 by selecting “Open in 32-bit mode” from the application’s Finder properties).

SPNEGO aka “negotiate-auth” support is necessary to make use of Cosign, the GSSAPI-based web single-signon system as employed by Informatics’ “weblogin” service. Like most advanced Chrome configuration, SPNEGO support can only be enabled by means of command-line manipulation.

The argument listed at the URL above was not sufficient to allow the credential delegation necessary to accomplish more interesting tasks with Cosign. Some digging through the code turned up the following pair of magic arguments, the latter of which appears to be documented only at the bottom of another enhancement request:

  • --auth-server-whitelist
  • --auth-negotiate-delegate-whitelist

<s:
Specifically, to make use of Informatics' weblogin service, Chrome (on linux) needs only to be launched with:


/path/to/chrome --auth-server-whitelist="weblogin.inf.ed.ac.uk"
--auth-negotiate-delegate-whitelist="weblogin.inf.ed.ac.uk" "$*"

Having discovered the magic incantation, permanently altering the launch environment in Windows or Linux is trivial, by means of shortcut or shell script. Mac OS X, on the other hand, presents the usual “think different” challenge. There does not appear to be any (easy) way to attach arguments to a graphically-launched application; it seems like some .app hacking is always required.

Thankfully, application creation is not difficult, and making a replacement application suitable for use in the dock is relatively straightforward. This script even extracts Chrome’s icon from app.icns for the shiny new cosign-enabled wrapper.

# Adjust existing and augmented Chrome locations to taste:
oldapp="/Applications/Google Chrome.app"
newapp="/Applications/Chrome SPNEGO.app"
# Create the wrapper application
newbin="${newapp}/Contents/MacOS/Chrome"
args='--auth-server-whitelist="weblogin.inf.ed.ac.uk"\
 --auth-negotiate-delegate-whitelist="weblogin.inf.ed.ac.uk"'
mkdir -p "${newapp}/Contents/MacOS" "${newapp}/Contents/Resources"
ln -s "${oldapp}/Contents/Resources/app.icns" "${newapp}/Contents/Resources/"
defaults write "${newapp}/Contents/Info" CFBundleExecutable "Chrome"
defaults write "${newapp}/Contents/Info" CFBundleIconFile "app.icns"
cat >"${newbin}" <<_EOF_
#!/bin/bash
open "${oldapp}" --args ${args} "\$*"
_EOF_
chmod +x "${newbin}"

Limitations

Although a fully-fledged application, its only purpose is to launch another one and you’ll note that a second Chrome icon representing the ‘real’ application will appear on your dock once launched. There are ways to work around this, such as renaming the Chrome binary, replacing it with the wrapper, but this technique has other drawbacks such as breaking application signatures or automatic updates. Suggestions below, please!

Another drawback of the wrapper-app is that our minimal Info.plist will likely not handle dropped URLs or local files very well; the “real” chrome will still be registered as the actual browser, which means that Chrome instances launched by association will not enjoy spnego support. Perhaps the real Chrome’s Info.plist could be reused in some way to steal file associations.

Further suggested augmentations would be to have the wrapper script read all command-line arguments from the Application (or the user’s) plist file via defaults.

5 thoughts on “Chrome and SPNEGO

  1. hugh.cole-baker@ed.ac.uk

    You can get rid of the requirement for a wrapper script and command-line arguments on the Mac completely if you set a managed preference for Chrome on your user account.
    http://www.afp548.com/article.php?story=using-mcx-in-the-dslocal-domain explains a bit about this.

    The relevant commands would be:
    sudo dscl . -mcxset /Users/yourusername com.google.Chrome AuthServerWhitelist always weblogin.inf.ed.ac.uk
    sudo dscl . -mcxset /Users/yourusername com.google.Chrome AuthNegotiateDelegateWhitelist always weblogin.inf.ed.ac.uk

    Then Chrome will apply these settings whenever it’s started, even without the command line flags.

  2. Pingback: Deploying mod_spnego | Cats and Code

  3. Pingback: Chrome GSSAPI / SPNEGO | Pearltrees

Leave a Reply

Your email address will not be published. Required fields are marked *