RFR 6722928: Support SSPI as a native GSS-API provider

[Nico Williams]

On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote:
> Practically, if I always add the current realm to a name without a realm, and
> then always remove the realm if it's the current realm when calling
> InitiateSecurityContext, there should be no harm. If the realm was added by
> me, then removing it loses no info. If it was added by the user and it's the
> current realm, I hope when there is no realm InitiateSecurityContext will
> always try the local realm first.

But then you have to keep track of whether you added it or not.  Can you
just use the empty realm like Heimdal and MIT do?

> In fact, as I have observed, even if I don't remove the current realm
> from a name, InitiateSecurityContext is still doing the correct thing.
> I think the reason is that service/host@ and
> service/host at CURRENT.REALM are the same in a KDC-REQ, and even if
> there is a realm it still sets CANONICALIZE and accepts referrals.

Ah, but if it's not the "current" realm?  (What do you mean by "current"
anyways?)

> Here is the latest webrev
> 
>    http://cr.openjdk.java.net/~weijun/6722928/webrev.07/
> 
> Comparing to the last version (you can see in the interdiff.patch):
> 
> 1. Rename KRB5_TRACE to SSPI_TRACE and always write to stderr.

I would think JDK_SSPI_TRACE would be a better name...

> 2. No more guessing realm in get_full_name().

Good.

> 3. Some cleanup.
> 
> You can see that since I haven't retain the name type, I translate
> service at host to service/host right at the importing, and treat any
> name as KRB5 name later on.

Sure, because that's how SSPI works :)

I'll probably not get to review till next week.

Nico
--