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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos