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

[Michael Osipov]

Am 2019-03-22 um 20:43 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.
> 
> 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()).

acquireCredFrom() is a must have for multi-tenancy and services. Think 
of TLS virtual hosting with one keytab per host on a Tomcat.

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

Michael