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

[Michael Osipov]

Am 2019-03-22 um 20:29 schrieb Nico Williams:
> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
>> Am 2019-03-22 um 16:28 schrieb Nico Williams:
>>>    - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>>>      to the ServicePermission stuff
>>
>> Granted.
>
> :(
>
>>> IMO JAAS (and with it, *Permission) should be removed with prejudice now
>>> that applet support has been removed.  Perhaps stubs should be left
>>> behind for compatibility reasons, and all the doAs*() methods should
>>> just act as though permission is granted.
>>>
>>> Removing JAAS would be a wonderful simplification, then the JGSS stuff
>>> could stop being Kerberos-specific.
>>
>> Fully agree, it has been a pain in the last couple of years. This would
>> also require an RFC update for the JGSS bindings to logon onto network
>> with username/password or keytab w/o login modules.
>
> Our contributions add acquireCredWithPassword() methods.
>
> And we could add acquireCredFrom() to match gss_acquire_cred_from() /
> gss_add_cred_from() (a Heimdal and MIT innovation that allows, among
> other things, to use a specific keytab).

Based on this:
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_ext.h

That would be awesome. We have several use cases for keytabs:

1) traditional one, machine account with SPNs (acceptor, sometimes
initiator)
2) service account (initiator)
3) service account with SPNs (both)

That would make JAAS and the Krb5LoginModule completely obsolete.

> But also, most JGSS users don't need the JDK to have this functionality
> since using kinit externally and KRB5* env vars works perfectly fine for
> the vast majority of cases.

I see several cases not covered if MIT Kerberos is used:

1)
# export KRB5_CLIENT_KTNAME=/etc/krb5.keytab
# curl --negotiate -u : ...do magic...

will simply not work with a keytab created by Samba because the machine
UPN is not the first entry of the table. One would require
KRB5_CLIENT_PRINCIPAL for that. It would cover gss_acquire_cred_from()
with the gss_name_t.

2) non-file based ccaches cannot be accessed by Java ATM (e.g., keyring).

3) serialization of credentials to disk for futher usage (e.g.,
credetial delegation)

4) Consider you use MIT Kerberos via JGSS and receive a delegated
credential via HTTP, you store that in the request (no session). There
is no Servlet API callback that the request has been disposed, you
cannot call GSSCredential#dispose(). It will or may lead to a memory
leak. I don't know whether the GC will handle this. Frankly, I need to
check mod_auth_gssapi how they solve that because that memory does not
come from apr_pool_t.

But I really would like to see
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
coming.

Michael