I've thought about this over and have the following plan:
Since GSSName::isMN is always true, every gss_name_t must be a MN and I decide
the name to be always krb5 style and the type to be always NT_KRB5_NAME.
However, somewhere in the JGSS native bridge implementation the name and type
are cached on the Java side, therefore the result of
gSSMananger.createName("service@host", NT_HOSTBASED_SERVICE) does have
toString() being service@host and type being NT_HOSTBASED_SERVICE. When
canonicalize() is called, even if the GSS-API canonicalize_name() is not called
a new gss_name_t is created and the Java side cache will be recreated, and this
time name becomes service/host and type becomes NT_KRB5_NAME.
Is this what you like to see?
As for export(), I can also output a/b@. When the result is imported as a
NT_EXPORT_NAME, I'll remember to remove the @ at the end.
The result is:
GSSManager m = GSSManager.getInstance();
GSSName n = m.createName("service@host", GSSName.NT_HOSTBASED_SERVICE);
// n is now (service@host, NT_HOSTBASED_SERVICE)
n = n.canonicalize(new Oid("1.2.840.113554.1.2.2"));
// n is now (service/host, NT_KRB5_NAME)
byte[] x = n.export();
// 0000: 04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 00 ......*.H.......
// 0010: 00 00 0D 73 65 72 76 69 63 65 2F 68 6F 73 74 40 ...service/host@
n = m.createName(x, GSSName.NT_EXPORT_NAME);
// n is now (service/host, NT_KRB5_NAME)
Thanks
Max
> On Dec 5, 2018, at 11:41 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
>
> 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.willi...@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.w...@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@hostname -> service/hostname@).
>>>>
>>>> OK.
>>>
>>> I'm playing with the Java native bridge to MIT krb5 and noticed that
>>> whatever
>>> GSSName I created (user, user@REALM, service@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@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@R a a@R a a@R
>>> a a@R
>>> s@h s@h s/h@ s@h s/h@ s/h s/h@R
>>> s/h s/h@R
>>
>> Speaking of @<empty-realm>, I should read up on how to implement
>> referrals on the client side using SSPI...
>>
>> Nico
>> --
>
