You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to implement Kerberos Authentication, there is no need to register a custom Configuration; current implementation leads to extra processing time and unnecessary memory usage, that will affect not only this driver code but all other code/runtime that uses JAAS.
When using kerberos authentication, the diver registers a configuration with a call to javax.security.auth.login.Configuration.setConfiguration, performed from a class static block in class com.microsoft.sqlserver.jdbc.KerbAuthentication with code Configuration.setConfiguration(new JaasConfiguration(Configuration.getConfiguration()));.
A call to Configuration.setConfiguration, should not be performed from a JDBC Driver; it is a security configuration and should be set only by Java Runtime, Java EE/Jakarta EE container or some very specific security related library.
The implementation in class com.microsoft.sqlserver.jdbc.JaasConfiguration, adds some logic that adds default values, that will only be triggered if the login module SQLJDBCDriver is defined with an empty configuration:
SQLJDBCDriver {
};
Note: The login/module used by default is SQLJDBCDriver, but this can be parametrized to a different name using diver property jaasConfigurationName since version 12.6+.
If a login module is empty (with its a valid configuration), it should be used it "as is", with defaults set by runtime, login will probably fail; the login configurations need to be set correctly, as documented under Using Kerberos integrated authentication to connect to SQL Server.
If we tried to perform login with default configurations added by JaasConfiguration or with empty login configuration, exceptions will be thrown. Some examples when calling javax.security.auth.login.LoginContext#login, with those type of configurations
javax.security.auth.login.LoginException: No LoginModules configured for SQLJDBCDriver
javax.security.auth.login.LoginException: No CallbackHandler available to garner authentication information from the user
java.lang.IllegalArgumentException: No Configuration was registered that can handle the configuration named SQLJDBCDriver
The configuration registered by driver is not even guaranteed to be in effect; if we have for example other libraries that register similar configurations, what's called depends on the order that configurations were registered.
Also when setting drivers property useDefaultJaas=true, the registered configuration is not event used, and a new instanced of JaasConfiguration is created (does this work with default values?)
If any code/library that needs to perform this type of authentication registered a configuration we will end up with various chained configuration.
Removing the call, will add following benefits
simpler code.
more performant during load of driver classes, and at runtime as less chained falls for configuration.getAppConfigurationEntry.
less memory will be used, an instance of com.microsoft.sqlserver.jdbc.JaasConfiguration will not be created and placed in memory.
Actions
Remover call javax.security.auth.login.Configuration.setConfiguration from static block in class com.microsoft.sqlserver.jdbc.KerbAuthentication
Side note: Removing this code also removes the need to grant permission javax.security.auth.AuthPermission setLoginConfiguration, if a Java Security Manager is defined. Here we can take in consideration that Java Security Manager was deprecated by JEP 411: Deprecate the Security Manager for Removal as of JDK 17, and planned to be removed by JEP 486: Permanently Disable the Security Manager.
The text was updated successfully, but these errors were encountered:
In order to implement Kerberos Authentication, there is no need to register a custom Configuration; current implementation leads to extra processing time and unnecessary memory usage, that will affect not only this driver code but all other code/runtime that uses JAAS.
When using kerberos authentication, the diver registers a configuration with a call to
javax.security.auth.login.Configuration.setConfiguration
, performed from a class static block in classcom.microsoft.sqlserver.jdbc.KerbAuthentication
with codeConfiguration.setConfiguration(new JaasConfiguration(Configuration.getConfiguration()));
.A call to
Configuration.setConfiguration
, should not be performed from a JDBC Driver; it is a security configuration and should be set only by Java Runtime, Java EE/Jakarta EE container or some very specific security related library.The implementation in class
com.microsoft.sqlserver.jdbc.JaasConfiguration
, adds some logic that adds default values, that will only be triggered if the login moduleSQLJDBCDriver
is defined with an empty configuration:Note: The login/module used by default is
SQLJDBCDriver
, but this can be parametrized to a different name using diver propertyjaasConfigurationName
since version 12.6+.If a login module is empty (with its a valid configuration), it should be used it "as is", with defaults set by runtime, login will probably fail; the login configurations need to be set correctly, as documented under Using Kerberos integrated authentication to connect to SQL Server.
If we tried to perform login with default configurations added by JaasConfiguration or with empty login configuration, exceptions will be thrown. Some examples when calling
javax.security.auth.login.LoginContext#login
, with those type of configurationsjavax.security.auth.login.LoginException: No LoginModules configured for SQLJDBCDriver
javax.security.auth.login.LoginException: No CallbackHandler available to garner authentication information from the user
java.lang.IllegalArgumentException: No Configuration was registered that can handle the configuration named SQLJDBCDriver
The configuration registered by driver is not even guaranteed to be in effect; if we have for example other libraries that register similar configurations, what's called depends on the order that configurations were registered.
Also when setting drivers property
useDefaultJaas=true
, the registered configuration is not event used, and a new instanced of JaasConfiguration is created (does this work with default values?)If any code/library that needs to perform this type of authentication registered a configuration we will end up with various chained configuration.
Removing the call, will add following benefits
configuration.getAppConfigurationEntry
.com.microsoft.sqlserver.jdbc.JaasConfiguration
will not be created and placed in memory.Actions
Remover call
javax.security.auth.login.Configuration.setConfiguration
from static block in classcom.microsoft.sqlserver.jdbc.KerbAuthentication
Side note: Removing this code also removes the need to grant permission
javax.security.auth.AuthPermission setLoginConfiguration
, if a Java Security Manager is defined. Here we can take in consideration that Java Security Manager was deprecated by JEP 411: Deprecate the Security Manager for Removal as of JDK 17, and planned to be removed by JEP 486: Permanently Disable the Security Manager.The text was updated successfully, but these errors were encountered: