Many people are aware that MySQL 5.5 added support for external authentication plugins, and that Oracle provides several commercial-licensed plugins that can help users leverage this functionality out-of-the-box (you can try these and other features of MySQL commercial offerings for free). Until the recent release of Connector/J 5.1.19, though, JDBC users could not leverage the plugin capabilities of MySQL 5.5. Now, Java users can write their own client-side plugins in support of the standard MySQL 5.5 external authentication plugins, or even server-side external authentication plugins they write themselves.
This release (and this feature, specifically) is also significant in at least one other way: It’s the first release (and feature) of Connector/J authored by Alexander Soklakov – the newest member of the Connectors team and crack Java developer. Like most things at MySQL, there was a good team backing Alex up (with Mark Matthews helping define the architecture, Rafal Somla coordinating the protocol-level changes, and Tonci Grgin overseeing it all). Way to go, Alex and team!
Because the key MySQL 5.5 external authentication plugins are platform dependent (PAM, Windows), they may not be the best fit for Java users, where platform independence (and lack of reliance on native code) is a big priority. We’re always interested to receive feature requests, though, so if you have an idea for how you would want to use MySQL external authentication in the context of your Java application, please let us know (comment here, or register the request at bugs.mysql.com).
The original purpose for writing this blog entry, however, was to supplement my previous entries on other Connector/J extension points. Much to my chagrin, but your benefit, Alexander was way ahead of me. The public docs haven’t quite caught up, but there’s great content in the CHANGES file. He even includes example and test implementations. I’ll just quote the CHANGES file directly:
- Added support for pluggable authentication via the com.mysql.jdbc.AuthenticationPlugin
interface (which extends standard "extension" interface). Examples are in
com/mysql/jdbc/authentication and in testsuite.regression.ConnectionRegressionTest.
This introduces three new properties:
authenticationPlugins defines comma-delimited list of classes that implement
com.mysql.jdbc.AuthenticationPlugin and which will be used for authentication
unless disabled by "disabledAuthenticationPlugins" property.
disabledAuthenticationPlugins defines comma-delimited list of classes implementing
com.mysql.jdbc.AuthenticationPlugin or mechanisms, i.e. "mysql_native_password".
The authentication plugins or mechanisms listed will not be used for authentication
which will fail if it requires one of them. It is an error to disable the default
authentication plugin (either the one named by "defaultAuthenticationPlugin" property
or the hard-coded one if "defaultAuthenticationPlugin" propery is not set).
defaultAuthenticationPlugin defines name of a class implementing
com.mysql.jdbc.AuthenticationPlugin which will be used as the default authentication
plugin. It is an error to use a class which is not listed in "authenticationPlugins"
nor it is one of the built-in plugins. It is an error to set as default a plugin
which was disabled with "disabledAuthenticationPlugins" property. It is an error
to set this value to null or the empty string (i.e. there must be at least a valid
default authentication plugin specified for the connection, meeting all constraints
listed above).
It’s great work from Alexander, and I’m looking forward to his future work. It also demonstrates the value of having a support organization with direct involvement in the development of all MySQL products, as this functionality was implemented in direct response to customer need.
Let us know if you have any problems implementing external authentication plugins, or have ideas on plugins you would find valuable for managing your Java deployments.
