about:nothing

Update: The landscape on OS X has changed since this post was written. Hugh Cole Baker provided in a comment an excellent mechanism for setting self-managed policy on OS X which beats my clunky wrapper; Lion’s Kerberos support has changed in a way which prevents SPNEGO working for our Cosign servers (though a fix at our end is planned); Chrome on Linux gained a proper managed configuration, which we use locally (I produced the lcfg-chrome component for this purpose).

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

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.