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