Obsolete and remove JAAS please (was Re: RFR 6722928: Support SSPI as a native GSS-API provider)

[Nico Williams]

On Sat, Mar 23, 2019 at 01:07:45AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:43 schrieb Nico Williams:
> > All LoginModule functionality that is used to acquire credentials should
> > be made available outside JAAS.  E.g., JGSS could use kinit-style
> > functionality (acquireCredWithPassword() and so on).  "Could use", not
> > "needs", because external use of kinit and KRB5* env vars works for 97%
> > of cases, though being able to cover 100% is nice, and since I've done a
> > lot of the necessary work (acquireCredWithPassword()), might as well do
> > the rest (i.e., add acquireCredFrom()).
> 
> acquireCredFrom() is a must have for multi-tenancy and services. Think of
> TLS virtual hosting with one keytab per host on a Tomcat.

I'm talking about multi-tenancy where you need isolation.

If you mereley want multiple hostnames (and to dispatch on them), then
on the server side you can always just check what name the initiator
called the acceptor by, and that's good enough.  (You have to put all
the relevant keys in the same keytab.)

If you need isolation, then you need acquireCredFrom() and an access
control mechanism.

> > It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult
> > reasons (i.e., devs copy-pasting what [appears to] works for others), or
> > else because the developers don't know how to use kinit externally.
> > 
> > The Krb5 stack appears to be practically abandoned and far behind all
> > other Kerberos implementations.  With our JGSS contributions (and Max's
> > SSPI bridge) there is also the opportunity to remove the Krb5 stack,
> > which would lighten the development and maintenance burden on Oracle
> > engineers, freeing up cycles for other, more interesting work.
> 
> That is true, but it would require to have a very good coverage via SSPI or
> MIT Kerberos on all platforms where Java runs, not just those Oracle
> officially supports. I do use the same code one four operating systems with
> Java.

We use the Martin Rex's gsskrb5 GSS->SSPI bridge, with our own patches
to it (mostly to remove code).  This has a license that has an
advertising clause, which is probably the only reason Oracle wouldn't
accept it.

You can find our fork here: https://github.com/twosigma/gsskrb5

It's missing channel binding support, and, of course, doesn't have some
of the newer extensions, but it does work.

One or both of Heimdal and MIT Kerberos work on all platforms that Java
does, no?  Though on Windows one really wants a GSS->SSPI bridge, even
though Heimdal and MIT have some support for using the LSA as a
credential store.

Nico
--