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