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

[Weijun Wang]

Java's GSSName::isMN always returns true, therefore to my observation, the GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. It is only called in export(), where the first call to export_name() might return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically call canonicalize_name() and export_name() again.

And then, the export format is only useful when importing a NT_EXPORT_NAME.

So, seems like both export_name() and canonicalize_name() are quite useless (at least in the view of the native bridge).

What's your ideal output? The toString of canonicalize() and import(export) always showing krb5 style and name type being KRB5_NAME?

--Max

> On Dec 5, 2018, at 4:34 AM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote:
>>> On Nov 29, 2018, at 10:00 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>> - gss_canonicalize_name() is not fully implemented.  This will be noticeable
>>>> to callers of GSSNameElement's getKrbName().  In particular, permissions
>>>> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
>>>> in NativeGSSContext).
>>>> 
>>>> At minimum you absolutely must parse generic GSS name type names into
>>>> Kerberos-style names (e.g., service at hostname -> service/hostname@).
>>> 
>>> OK.
>> 
>> I'm playing with the Java native bridge to MIT krb5 and noticed that whatever
>> GSSName I created (user, user at REALM, service at host) the toString() of the
>> original GSSName and its canonicalize(KRB5_OID) are always the same (and the
> 
> That, in principle, is a bug.  That should be evidence that little code out
> there cares.
> 
> But gss_display_name() on a generic-syntax imported name should be the same as
> the original input, while gss_display_name() on an MN is mechanism-specific,
> and for Kerberos should be a Kerberos-style name string.
> 
> Looking at the JGSS code, it looks like this buglet is in MIT.  I'll confirm
> later.
> 
>> same as the original input). On the other hand, the export() forms of them
>> are also the same and show Kerberos-style names.
> 
> Yes, code would definitely break if export() didn't do that...
> 
>> From the debug output, I can see the first export() call notices it's not MN
>> and canonicalize automatically.
>> 
>> In my library, since there is only one mechanism, the name is created as MN
>> at the beginning. So in import_name() you can see service at host is already
>> changed into service/host, canonicalize_name() does nothing, and
>> export_name() adds the realm. Is this also OK?
> 
> In principle no.  See above.
> 
>> Summary:
>> 
>> Input    MIT name    export     MIT mn     export    my name     export     my mn      export
>> -----    --------    ------     ------     ------    -------     ------     -----      ------
>> a        a           a at R        a          a at R       a           a at R        a          a at R
>> s at h      s at h         s/h@       s at h        s/h@      s/h         s/h at R      s/h        s/h at R 
> 
> Speaking of @<empty-realm>, I should read up on how to implement
> referrals on the client side using SSPI...
> 
> Nico
> --