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

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

I replied separately about the kinit functionality of Krb5LoginModule.

I want to call out the point that JAAS has no raison d'être in a world
without applets.

Even in a JVM multi-tenancy project (which I'm told there's continued
desire for), while there may be uses for doAs() and doAsPrivileged(),
those would be subtly but very different notions than in JAAS.  Any JVM
multi-tenancy project should either start from scratch, or if it will
reuse JAAS classes, should clean up the mess that is ServicePermissions
(and probably others).  (I would also argue against JVM multi-tenancy.)

IMO it would be better to remove JAAS altogether.

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

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.

Nico
--