Pluggable Authentication
When a client connects to the MariaDB server, the server uses the user name provided by the client and the client host to select the appropriate account row from the mysql.user
table. It then uses this row to authenticate the client.
In MariaDB 5.6, the server authenticates clients using plugins, as follows:
- The server determines from the account row which authentication plugin applies for the client:
- If the account row specifies no plugin name, the server uses native authentication; that is, authentication against the password stored in the
Password
column of the account row. This is the same authentication method provided by MariaDB servers older than 5.5.7, before pluggable authentication was implemented, but now is implemented using two plugins that are built in and cannot be disabled. - If the account row specifies a plugin, the server invokes it to authenticate the user. If the server cannot find the plugin, an error occurs.
- If the account row specifies no plugin name, the server uses native authentication; that is, authentication against the password stored in the
- The plugin returns a status to the server indicating whether the user is permitted to connect.
Pluggable authentication enables two important capabilities:
- External authentication: Pluggable authentication makes it possible for clients to connect to the MariaDB server with credentials that are appropriate for authentication methods other than native authentication based on passwords stored in the
mysql.user
table. For example, plugins can be created to use external authentication methods such as PAM, Windows login IDs, LDAP, or Kerberos. - Proxy users: If a user is permitted to connect, an authentication plugin can return to the server a user name different from the name of the connecting user, to indicate that the connecting user is a proxy for another user. While the connection lasts, the proxy user is treated, for purposes of access control, as having the privileges of a different user. In effect, one user impersonates another. For more information, see , "Proxy Users".
Several authentication plugins are available in MySQL. The following sections provide details about specific plugins.
- Plugins that perform native authentication that matches the password against the
Password
column of the account row. See , "The Native Authentication Plugins". Native authentication is the default for accounts that have no plugin named explicitly in their account row. - A client-side plugin that sends the password to the server without hashing or encryption. This plugin can be used by server-side plugins that require access to the password exactly as provided by the client user. See , "The Clear-Text Client-Side Authentication Plugin".
- A plugin that authenticates clients that connect from the local host through the Unix socket file. See , "The Socket Peer-Credential Authentication Plugin".
- A test plugin that authenticates using MariaDB native authentication. This plugin is intended for testing and development purposes, and as an example of how to write an authentication plugin. See , "The Test Authentication Plugin".
For information about current restrictions on the use of pluggable authentication, including which connectors support which plugins, see "Restrictions on Pluggable Authentication".
Third-party connector developers should read that section to determine the extent to which a connector can take advantage of pluggable authentication capabilities and what steps to take to become more compliant.
If you are interested in writing your own authentication plugins, see , "Writing Authentication Plugins".
In general, pluggable authentication uses corresponding plugins on the server and client sides, so you use a given authentication method like this:
- On the server host, install the appropriate library containing the server plugin, if necessary, so that the server can use it to authenticate client connections. Similarly, on each client host, install the appropriate library containing the client plugin for use by client programs.
- Create MariaDB accounts that specify use of the plugin for authentication.
- When a client connects, the server plugin tells the client program which client plugin to use for authentication.
The remainder of this section provides general instructions for installing and using authentication plugins. The instructions use an an example authentication plugin included in MariaDB distributions (see , "The Test Authentication Plugin"). The procedure is similar for other authentication plugins; substitute the appropriate plugin and file names.
The example authentication plugin has these characteristics:
- The server-side plugin name is
test_plugin_server
. - The client-side plugin name is
auth_test_plugin
. - Both plugins are located in the shared library object file named
auth_test_plugin.so
in the plugin directory (the directory named by theplugin_dir
system variable). The file name suffix might differ on your system.
Install and use the example authentication plugin as follows:
- Make sure that the plugin library is installed on the server and client hosts.
- Install the server-side test plugin at server startup or at runtime:
- To install the plugin at startup, use the
--plugin-load
option. For example, use these lines in amy.cnf
option file:
[mysqld] plugin-load=test_plugin_server=auth_test_plugin.so
With this plugin-loading method, the option must be given each time you start the server. The plugin is not installed if you omit the option.
- To install the plugin at runtime, use the
INSTALL PLUGIN
statement:
mysql>
INSTALL PLUGIN test_plugin_server SONAME 'auth_test_plugin.so';
This installs the plugin permanently and need be done only once.
PAM authentication, when not done through proxy users or groups, requires the MariaDB account to have the same user name as the Unix account. Because MariaDB user names are limited to 16 characters (see , "Privilege System Grant Tables"), this limits PAM nonproxy authentication to Unix accounts with names of at most 16 characters.
- To install the plugin at startup, use the
- Verify that the plugin is installed. For example, use
SHOW PLUGINS
:
mysql>
SHOW PLUGINS\G
... *************************** 21. row *************************** Name: test_plugin_server Status: ACTIVE Type: AUTHENTICATION Library: auth_test_plugin.so License: GPLFor other ways to check the plugin, see , "Obtaining Server Plugin Information".
- To specify that a MariaDB user must be authenticated using the plugin, name it in the
IDENTIFIED WITH
clause of theCREATE USER
statement that creates the user:
CREATE USER 'testuser'@'localhost' IDENTIFIED WITH test_plugin_server;
- Connect to the server using a client program. The test plugin authenticates the same way as native MariaDB authentication, so provide the usual
--user
and--password
options that you normally use to connect to the server. For example:
shell>
mysql --user=
your_name
--password=your_pass
For connections by
testuser
, the server sees that the account must be authenticated using the server-side plugin namedtest_plugin_server
and communicates to the client program which client-side plugin it must use-in this case,auth_test_plugin
.In the case that the account uses the authentication method that is the default for both the server and the client program, the server need not communicate to the client which plugin to use, and a round trip in client/server negotiation can be avoided. Currently this is true for accounts that use native MariaDB authentication (
mysql_native_password
).The
--default-auth=
option can be specified on the mysql command line to make explicit which client-side plugin the program can expect to use, although the server will override this if the user account requires a different plugin.plugin-name
If mysql does not find the plugin, specify a
--plugin-dir=
option to indicate where the plugin is located.dir_name
If you start the server with the --skip-grant-tables
option, authentication plugins are not used even if loaded because the server performs no client authentication and permits any client to connect. Because this is insecure, you might want to use --skip-grant-tables
in conjunction with --skip-networking
to prevent remote clients from connecting.