Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Driver should not override default JAAS configuration #2586

Open
bantunes opened this issue Jan 18, 2025 · 0 comments
Open

Driver should not override default JAAS configuration #2586

bantunes opened this issue Jan 18, 2025 · 0 comments

Comments

@bantunes
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To be triaged
Development

No branches or pull requests

1 participant