RFR 6722928: Support SSPI as a native GSS-API provider

Nico Williams Nico.Williams at twosigma.com
Fri Nov 30 16:37:56 UTC 2018

On Fri, Nov 30, 2018 at 10:12:12AM +0800, Weijun Wang wrote:
> Nowadays whenever we introduce a new security-related property, we are
> thinking about whether it can also be both a system property and a
> security property. If so, it can be set "permanently" in
> conf/security/java.security or "temporarily" as a system property. See
> https://hg.openjdk.java.net/jdk/jdk/file/d488477865c0/src/java.base/share/classes/sun/security/util/SecurityProperties.java#l45.

I don't see where that allows something like this property to be set via
some configuration file in /etc or via the registry on Windows.

Even if it does allow setting this via a config file in /etc, on Windows
it would be really nice to be able to use the registry.  E.g., because
there's better tooling for managing the registry than for managing
config files.

More generally, and to avoid unnecessary duplication, it'd be really
nice to be able to use Preferences, obviously in a cut-down way such
that only local files or the registry can be used.  I understand that
implementing such a thing for local XML files would be... difficult.  An
alternative might be to permit the ciruclar dependency, resolve it
somehow in the build system (e.g., move the Preferences interface /
abstract class into security but leave the implementations in utils),
and disallow access to anything other than local files and the registry
at run-time when invoked from security classes (to avoid infinite
loops) (e.g., using thread-local state).

IMO that would provide an excellent opportunity to improve usability
while also allowing the removal of all the registry access JNI code
outside Preferences.


More information about the security-dev mailing list