using kerberos to authenticate for a web api

[Rick van Rein]

Hi Chris,

Been looking at similar things:
> [...] I'd like to
> authenticate these API users with the same kerberos system.  What's the
> best way to do this?  Most APIs are authenticated with OAuth these days,
> but I don't see any turnkey hookup for Kerberos and OAuth.
The idea with OAuth as I understand it is to have a token-granting (or 
"authorising") web service pointed at in some way by the resource.  The 
communications format between resource and token-granter is opaque, and 
left to the imagination of these two parties.  IOW, it should be 
possible to pass a Kerberos ticket between the two.

Note that the "Bearer" token that springs to mind for this is not as 
secure as doing SPNEGO directly on the target resource!  The resource is 
deprived of options to ask the client to authenticate itself, because 
these "Bearer" tokens are a sort of passports.  This could be resolved 
with integration between resource and ticket granter, which IMHO sort of 
defeats the idea of splitting the resource and granting service for any 
purpose but having N resources and one granter.

And you should guard the Bearer token enviously, so as to avoid it being 
stolen by a rogue webpage plugin (ad? pixel?) so you'll be forced to use 
HTTPS.  I prefer to have a browser handle authorisation, and take it out 
of the claws of JavaScript code.  That's an opinion, and a rather candid 
one perhaps.
> There's mod_auth_kerb, but it hasn't been updated in a long time (maybe
> it just works?), [...]
mod_auth_kerberos works, but it is not really packed with features -- I 
specifically missed S4U2Proxy, to enable the module to speak on behalf 
of the user (under Constrained Delegation control).

What the module does is not difficult by the way -- it directly programs 
on top of GSSAPI, and could easily be done in any application that picks 
up the Authorization: header -- this is especially simple if the server 
chooses not to authenticate the client (for which another request is 
required).  I would like to see ${YOUR_FAVOURITE_SCRIPT_LANGUAGE-Python} 
module for SPNEGO, instead of being tied to Apache and this one module.
> [...] and it would require me to have API clients deal with
> SPNEGO.
>    
Yes.  It is not necessary for the client to take the initiative to send 
the "Authorization: Negotiate $BASE64GSSAPI" header, since it will be 
asked for it through "WWW-Authenticate: Negotiate", but I hardly think 
that static header would lead to stored state -- so you could simply 
send it immediately if you controlled the client.

If your clients are web browsers (sounds like that's what you mean) you 
would need to setup whitelisting, which is a measure to avoid sending 
tickets to anyone anywhere --think virtual hosting, and one of the 
vhosts needing SPNEGO-- so it will usually look like a list of domain 
names, with or without subname completion.

Browsers that I found supportive of SPNEGO:
  - FireFox has a whitelist option in its about:config option named 
"network.negotiate-auth.trusted-uris"
  - Google Chrome requires a cmdline option, has no GUI configuration option
  - Safari does not require whitelisting (and so it really scares me)
  - Konqueror supports SPNEGO, can't remember if it needed configuration
  - Curl has commandline options to enable SPNEGO
  - IE supports SPNEGO -- it was the first one

Not all browsers support SPNEGO though; for those you'd need a HTTP 
proxy or a platform change:
  - Opera does not, in spite of several requests
  - wget does not


> Any advice here?
>    
I hope some of these ramblings are useful to you.


Cheers,

Rick van Rein
OpenFortress