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

[Nico Williams]

On Sat, Mar 23, 2019 at 01:03:17AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:29 schrieb Nico Williams:
> > 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.

Yes, that's the idea.

> > 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.

You can set KRB5_CLIENT_KTNAME to deal with that.

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

If you're using the JGSS native C JNI interface and MIT Kerberos (or the
upcoming Heimdal 8.0), then you can use the Linux kernel keyring.

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

This definitely requires JGSS bindings for gss_store_cred() and
gss_store_cred_into().

> 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.

At least our patches do let you dispose of it.

> But I really would like to see
> https://secure-web.cisco.com/1QDhZ_p9aOLNhO8eSoC7nft6Vay_RWeIFcEMzgJqDQfx-5XV1-ueeUw9GWNtzl_Hsj8Qqmlg9P3VX-LqydOZN2u2bqSJMC7w5TOPYv48kYSl5USixBe75-RKm9cgK2ZDYK2mqkX4b83Tud3TUffwL5SRkf-mpbHvE6YC5nANzW1Lwx0NB9AIsP2FhqBe9fp1KYXdYbknF2prfVcXKpUu81nnWnwfRhXr1Ror2TF75RRZbs-ON27jRx7Cm7LoxLmNJgDCi-AaB41hmGV9KUJKkEQ/https%3A%2F%2Fk5wiki.kerberos.org%2Fwiki%2FProjects%2FCredential_Store_extensions
> coming.

Yes.

Direct link:

https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions

Nico
--