using kerberos to authenticate for a web api

[Simo Sorce]

On Tue, 2013-11-05 at 11:28 +0100, Rick van Rein wrote:
> 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?), [...]

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).

I am not sure about upstream but the version we distribute in Fedora and
RHEL has Constrained delegation support (specifically S4U2Proxy).

> 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.

There are many bindings for GSSAPI, and that would handle SPNEGO for
you, all you need to do is pass the SPNEGO OID to gss_init_sec_context()

> 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)

TBH if the KDC has no keys for the destination host,
gss_init_sec_context would just fail, so maybe whitelisting is not all
that necessary from a security pov for krb5.
OTOH if your GSSAPI implementation supports other mechanisms beyond Krb5
it may end up disclosing data to some degree ...

>   - 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.

As well,
HTH.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York