On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote: > > - You're constructing SPNEGO tokens yourself. I'll have to review that > > very carefully. > > I wrapped the outgoing token into NetTokenInit and extracted in incoming > NegTokenTarg. This might fail if there are multiple rounds, but I think for > kerberos it's OK.
Kinda. We'd like to add an option for multiple round trips to the Kerberos mechanism to make it easier to recover from various errors. You shouldn't assume that Kerberos will always be just one round trip. Of course, the chances that MSFT will implement our multi-round trip extension are probably so close to zero that you can get away with it :/ You could still support multiple round trips just fine, of course, but how to test it? One thing I've wanted to be able to do is to use concrete mechanisms via the JGSS JNI native C interface, but SPNEGO being JGSS native Java coded. That would allow multiple native JNI C providers for different mechanisms! (I'm sure Martin Rex / SAP would love that. They have a GSS mechanism provider building toolkit that SAP customers use to build many many custom mechanisms.) The JGSS mechglue needs additional work to make that possible, and if I remember correctly I left a few breadcrumb comments about that in our contribution. > > It would be better to let Windows provide SPNEGO though... > > But it might promote NTLM. You can make sure it doesn't get used. > > (I would also urge you to NOT attempt any DNS canonicalization of > > hostnames. Let's not further spread that mistake.) > > I didn't. I know. I meant that when you get around to parsing generic syntax names you might get tempted to do that, but if you are tempted, don't do it :) > > For user principals it's trickier, and I think you might need some notion > > of > > default realm, but a) maybe you can get away with an empty realm here on > > Windows, b) I'm not sure where you'd a default realm on Windows. > > I'm using the environment variable USERDNSDOMAIN now. Sure, that works for now. > > What we do to determine the default realm for user names in our > > patched version of Martin Rex's GSS->SSPI bridge is call > > AcquireCredentialsHandle() or QueryCredentialsAttributesW() to > > get/query the default credential and get its name, and from that the > > realm, and we use that as the default realm. > > > > I'll have to look and see how we handle host-based service names > > (Martin's original code has a domain_realm table in the registry, but > > we removed all of that and rely on referrals instead.) > > > > - If you can get Legal approval for including / distributing a fork of > > Martin Rex's bridge, you'll get all of the above functionality and > > also acceptor functionality. > > Anyway, one can use his bridge with -Dsun.security.jgss.lib. Indeed, one can! That reminds me, we need to publish our changes to it. A very cut-down (initiator-only) SSPI bridge will probably do for you for now. I wouldn't insist on acceptor functionality. But it is important that the bridge work with JAAS. Unfortunately a lot of projects (many of them Apache ones) have cargo-culted the use of JGSS w/ JAAS. Indeed, that is the main motivator for our contribution: that the use of JGSS w/ JAAS meant the native GSS providers couldn't be used because GSSName is not a Principal and because there was no GssLoginModule. I will ask for permission to exfiltrate a handful of test programs we use for testing basic JGSS w/ JAAS functionality. You should test the SSPI bridge with our patches and these programs. Note though that we don't actually test with any policies that would restrict what credentials the test program can use. In general we find JAAS to be pretty useless in a world with no applets -- no untrusted code. All the ServicePermission stuff is very Kerberos-specific and there is no support for other mechanisms :( Nico --
