Kerberos Safari Support (or lack thereof): CNAMEs + Negotiate Auth
MetaCarta used Kerberos for single-sign-on support company wide.
Now, given that MetaCarta was a bunch of MIT hackers, this shouldn’t be particularly shocking. 🙂 It was generally a very nice thing to have — although it got me used to the idea that I *shouldn’t* type my password 20 times per day, a notion that Nokia has tried very hard to dissuade me from.
However, Kerberos support in Safari never worked for MetaCarta’s web services. It was never clear to me why, it was just clear that it didn’t work. Googling showed me many people saying it did work, and no people saying it didn’t, so I figured it was some quirk of my system and didn’t bother to fix it.
Now, at Nokia, I’m in the same boat: for services run by the Group Formerly Known as MetaCarta, we use Kerberos for everything. The difference is, falling back to Basic auth — which was fine in MetaCarta times — is a Very Expensive path to take in the new world; our auth services are slow Microsoft AD services hosted thousands of miles away on the other side of multiple high-latency firewalls, so when Kerberos doesn’t work — it hurts.
So, after getting fed up with this behavior yesterday, I started digging in. I didn’t make a lot of progress last night, but this morning, I stumbled across a post documenting that Safari does not work with hosts that are CNAMEs. With that one small pointer, I found other evidence of people running into this, and an option to reproduce the Safari-like behavior in chrome: “–disable-auth-negotiate-cname-lookup”. (The option documentation points to HttpAuthHandlerNegotiate::CreateSPN in http auth handler for more details.)
This bad behavior isn’t limited to Safari though: different versions of IE and the .Net framework also fail in similar ways at times. (The article in question says “Do not use CNAME dns records and non default web ports when using Kerberos!” — and given the multitude of clients and differing bugs in implementation, I’d say that seems like about the right approach.)
This seems to be a bug in Safari; it isn’t clear to me if it’s also a bug in WebKit. A brief (30 minutes) search through webkit and related postings seems to indicate that the higher level authentication handlers — like the one linked above in Chrome — are implemented at the application level, not the library level. (The library provides the hooks, but wouldn’t have anything more complex like Kerberos — which isn’t surprising.) I think that would mean this is a bug in the Safari implementation — the closed source side that I can’t touch — rather than in the open source WebKit base, so I can’t just ‘fix it myself’ (other than writing my own application layer — or more realistically, switching away from Safari to Chrome).
Anyway, if you’re having an issue with Negotiate auth not working in Safari, when you think it should — check if the server you’re trying to talk to is using a CNAME. If the answer is yes, it seems you’ve run into a known limitation: Safari Just Doesn’t Do That.