using kerberos to authenticate for a web api

Simo Sorce simo at
Tue Nov 5 07:48:20 EST 2013

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

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,


Simo Sorce * Red Hat, Inc * New York

More information about the Kerberos mailing list