Benjamin Coddington <[email protected]> writes: > On Apr 11, 2014, at 8:58 PM, Russ Allbery <[email protected]> wrote:
>> I'm tempted to say that the right solution to this problem is to just >> attempt validation with every unique principal stored in the WebKDC >> keytab and say we're all good if validation against any of them works. >> That's roughly what the MIT Kerberos library defaults now do if the >> principal passed in is NULL, although they only try every host/* >> principal listed in the keytab. > I'm getting the sense that this approach would be acceptable, so I'll > start working on it. I'll need to make sure that the userinfo callout > would still work if the WebKdcUserInfoPrincipal isn't set and the > trusting realm's key is the first in the keytab. WebKdcUserInfoPrincipal is the remote principal to which you're authenticating, so is unrelated. You will need to set the second argument to WebKdcKeytab to the principal that you want to use for all purposes other than validation (such as reading authenticated requests from a WAS). Otherwise, it will use the first principal in the keytab. Otherwise, I think using anything in the keytab that works would be fine. The only security risk that I can think of is that this will open an attack if there are insecure keys in the keytab used by the WebKDC, but this seems like an easy thing to avoid. > Great! I've only a little time for this presently, so please pardon my > response latency. I'll plan on investigating the userinfo case and the > invalid key case and respond. Not a problem. I'm in a similar situation: working on a password strength rollout and operating system upgrades, and therefore not having the time to work on WebAuth that I'd like. -- Russ Allbery <[email protected]> Technical Lead, Infrastructure Delivery Group, Stanford University
