On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin <abakh...@openjdk.org> wrote:
> JGSS is implemented in the JVM in 2 levels: the standard Java security > provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS > login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. > The problem is that in this hierarchy, the login module doesn't go through > the provider, but tries to read the credential cache (which is blocked by the > credential guard in Win platform). This is not an issue if Kerberos is used > via the JGSS API because it automatically does the JAAS login as needed, and > won't do it at all if a native implementation is used. However many libraries > (even some built-in ones in the JVM) still needlessly call login() before > using JGSS. > > This patch represents the configuration option ( `“doNotLogin”` ) to allow > skipping the login, with a system property (`“sun.security.auth.skipLogin”`) > to set the default value if this option is not provided. This way it would > not break the regular Java Kerberos provider and allow users to both > individually (via JAAS configs) and globally (via the property) set the > expected behavior Any particular reason why the configuration option is not called `skipLogin`? Seems to me that setting "doNot" to `true` requires a bit of unnecessary metal boolean algebra and is easier to get wrong. Or is this for consistency with `doNotPrompt`? My general preference is to avoid using "negative" options such that when something is disabled or skipped, the value can be set to `false` instead of `true`. So I would prefer `doLogin=false` over `skipLogin=true`. But I guess this is a matter of preference and since all other configuration options seem to default to `false`, consistency might be an issue also in this regard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677662703
