23.2.4.9. Writing Authentication Plugins

Declare the server-side plugin with the usual general descriptor format that is used for all server plugin types (see Section 23.2.4.2.1, "Server Plugin Library and Plugin Descriptors"). For the auth_simple plugin, the descriptor looks like this:

mysql_declare_plugin(auth_simple){  MYSQL_AUTHENTICATION_PLUGIN,  &auth_simple_handler,                 /* type-specific descriptor */  "auth_simple",                        /* plugin name */  "Author Name",                        /* author */  "Any-password authentication plugin", /* description */  PLUGIN_LICENSE_GPL,                   /* license type */  NULL,                                 /* no init function */  NULL,                                 /* no deinit function */  0x0100,                               /* version = 1.0 */  NULL,                                 /* no status variables */  NULL,                                 /* no system variables */  NULL,                                 /* no reserved information */  0                                     /* no flags */}mysql_declare_plugin_end;

The name member (auth_simple) indicates the name to use for references to the plugin in statements such as INSTALL PLUGIN or UNINSTALL PLUGIN. This is also the name displayed by SHOW PLUGINS or INFORMATION_SCHEMA.PLUGINS.

The auth_simple_handler member of the general descriptor points to the type-specific descriptor. For an authentication plugin, the type-specific descriptor is an instance of the st_mysql_auth structure (defined in plugin_auth.h):

struct st_mysql_auth{  int interface_version;  const char *client_auth_plugin;  int (*authenticate_user)(MYSQL_PLUGIN_VIO *vio, MYSQL_SERVER_AUTH_INFO *info);};

The st_mysql_auth structure has three members: The type-specific API version number, the client plugin name, and a pointer to the main plugin function that communicates with the client. The client_auth_plugin member should indicate the name of the client plugin if a specific plugin is required. A value of NULL means "any plugin." In the latter case, whatever plugin the client uses will do. This is useful if the server plugin does not care about the client plugin or what user name or password it sends. For example, this might be true if the server plugin authenticates only local clients and uses some property of the operating system rather than the information sent by the client plugin.

For auth_simple, the type-specific descriptor looks like this:

static struct st_mysql_auth auth_simple_handler ={  MYSQL_AUTHENTICATION_INTERFACE_VERSION,  "auth_simple",           /* required client-side plugin name */  auth_simple_server       /* server-side plugin main function */};

The main function takes two arguments representing an I/O structure and a MYSQL_SERVER_AUTH_INFO structure. The structure definition is found in plugin_auth.h. It looks like this:

typedef struct st_mysql_server_auth_info{  char *user_name;  unsigned int user_name_length;  const char *auth_string;  unsigned long auth_string_length;  char authenticated_as[MYSQL_USERNAME_LENGTH+1];   char external_user[512];  int  password_used;  const char *host_or_ip;  unsigned int host_or_ip_length;} MYSQL_SERVER_AUTH_INFO;

The character set for string members is UTF-8. If there is a _length member associated with a string, it indicates the string length in bytes. Strings are also null-terminated.

When an authentication plugin is invoked by the server, it should interpret the MYSQL_SERVER_AUTH_INFO structure members as follows. Some of these are used to set the value of SQL functions or system variables within the client session, as indicated.

The auth_simple main function, auth_simple_server(), reads the password (a null-terminated string) from the client and succeeds if the password is nonempty (first byte not null):

static int auth_simple_server (MYSQL_PLUGIN_VIO *vio,                               MYSQL_SERVER_AUTH_INFO *info){  unsigned char *pkt;  int pkt_len;  /* read the password as null-terminated string, fail on error */  if ((pkt_len= vio->read_packet(vio, &pkt)) < 0)    return CR_ERROR;  /* fail on empty password */  if (!pkt_len || *pkt == '\0')  {    info->password_used= PASSWORD_USED_NO;    return CR_ERROR;  }  /* accept any nonempty password */  info->password_used= PASSWORD_USED_YES;  return CR_OK;}

The main function should return one of the error codes shown in the following table.

For an example of how the handshake works, see the plugin/auth/dialog.c source file.

The error codes following CR_ERROR are available from MySQL 5.6.5. The server counts plugin errors in the Performance Schema host_cache table, also available as of MySQL 5.6.5.

auth_simple_server_main() is so basic that it does not use the authentication information structure except to set the member that indicates whether a password was received.

A plugin that supports proxy users must return to the server the name of the proxied user (the MySQL user whose privileges the client user should get). To do this, the plugin must set the info->authenticated_as member to the proxied user name. For information about proxying, see Section 6.3.8, "Proxy Users", and Section 23.2.4.9.4, "Implementing Proxy User Support in Authentication Plugins".

Declare the client-side plugin descriptor with the mysql_declare_client_plugin() and mysql_end_client_plugin macros (see Section 23.2.4.2.3, "Client Plugin Descriptors"). For the auth_simple plugin, the descriptor looks like this:

mysql_declare_client_plugin(AUTHENTICATION)  "auth_simple",                        /* plugin name */  "Author Name",                        /* author */  "Any-password authentication plugin", /* description */  {1,0,0},                              /* version = 1.0.0 */  "GPL",                                /* license type */  NULL,                                 /* for internal use */  NULL,                                 /* no init function */  NULL,                                 /* no deinit function */  NULL,                                 /* no option-handling function */  auth_simple_client                    /* main function */mysql_end_client_plugin;

The descriptor members common to all client plugins are the plugin name through the option-handling function. Following the common members, an authentication plugin also has one extra member. This is the "main" function, which handles communication with the server. The function takes two arguments representing an I/O structure and a connection handler. For our simple any-password plugin, the main function does nothing but write to the server the password provided by the user:

static int auth_simple_client (MYSQL_PLUGIN_VIO *vio, MYSQL *mysql){  int res;  /* send password as null-terminated string in clear text */  res= vio->write_packet(vio, (const unsigned char *) mysql->passwd,                          strlen(mysql->passwd) + 1);  return res ? CR_ERROR : CR_OK;}

The main function should return one of the error codes shown in the following table.

CR_OK_HANDSHAKE_COMPLETE indicates that the client has done its part successfully and has read the last packet. A client plugin may return CR_OK_HANDSHAKE_COMPLETE if the number of round trips in the authentication protocol is not known in advance and the plugin must read another packet to determine whether authentication is finished.

To compile and install a plugin library object file, see the instructions in Section 23.2.4.3, "Compiling and Installing Plugin Libraries". To use the library file, it must be installed in the plugin directory (the directory named by the plugin_dir system variable).

Register the server-side plugin with the server. For example, to load the plugin at server startup, use a --plugin-load=auth_simple.so option (change the library suffix as necessary for your system).

Create a user for whom the server will use the auth_simple plugin for authentication:

mysql> CREATE USER
            'x'@'localhost'    -> IDENTIFIED WITH auth_simple;

Use a client program to connect to the server as user x. The server-side auth_simple plugin communicates with the client program that it should use the client-side auth_simple plugin, and the latter sends the password to the server. The server plugin should reject connections that send an empty password and accept connections that send a nonempty password. Invoke the client program each way to verify this:

shell> mysql --user=x
            --skip-passwordERROR 1045 (28000): Access denied for user 'x'@'localhost' (using password: NO)shell> mysql --user=x --password=abcmysql>

Because the server plugin accepts any nonempty password, it should be considered insecure. After testing the plugin to verify that it works, restart the server without the --plugin-load option so as not to indavertently leave the server running with an insecure authentication plugin loaded. Also, drop the user with DROP USER 'x'@'localhost'.

For additional information about loading and using authentication plugins, see Section 5.1.8.1, "Installing and Uninstalling Plugins", and Section 6.3.7, "Pluggable Authentication".

If you are writing a client program that supports the use of authentication plugins, normally such a program causes a plugin to be loaded by calling mysql_options() to set the MYSQL_DEFAULT_AUTH and MYSQL_PLUGIN_DIR options:

char *plugin_dir = "path_to_plugin_dir";char *default_auth = "plugin_name";/* ... process command-line options ... */mysql_options(&mysql, MYSQL_PLUGIN_DIR, plugin_dir);mysql_options(&mysql, MYSQL_DEFAULT_AUTH, default_auth);

Typically, the program will also accept --plugin-dir and --default-auth options that enable users to override the default values.

Should a client program require lower-level plugin management, the client library contains functions that take an st_mysql_client_plugin argument. See Section 22.8.14, "C API Client Plugin Functions".

One of the capabilities that pluggable authentication makes possible is proxy users (see Section 6.3.8, "Proxy Users"). For a server-side authentication plugin to participate in proxy user support, these conditions must be satisfied:

In other words, the only aspect of proxy user support required of the plugin is that it set authenticated_as to the proxied user name. The rest is optional (setting external_user) or done by the DBA using SQL statements.

How does an authentication plugin determine which proxied user to return when the proxy user connects? That depends on the plugin. Typically, the plugin maps clients to proxied users based on the authentication string passed to it by the server. This string comes from the AS part of the IDENTIFIED WITH clause of the CREATE USER statement that specifies use of the plugin for authentication.

The plugin developer determines the syntax rules for the authentication string and implements the plugin according to those rules. Suppose that a plugin takes a comma-separated list of pairs that map external users to MySQL users. For example:

CREATE USER ''@'%.example.com'  IDENTIFIED WITH my_plugin AS 'extuser1=mysqlusera, extuser2=mysqluserb'CREATE USER ''@'%.example.org'  IDENTIFIED WITH my_plugin AS 'extuser1=mysqluserc, extuser2=mysqluserd'

When the server invokes a plugin to authenticate a client, it passes the appropriate authentication string to the plugin. The plugin is responsible to:

For example, if extuser2 connects from an example.com host, the server passes 'extuser1=mysqlusera, extuser2=mysqluserb' to the plugin, and the plugin should copy mysqluserb into authenticated_as, with a terminating null byte. If extuser2 connects from an example.org host, the server passes 'extuser1=mysqluserc, extuser2=mysqluserd', and the plugin should copy mysqluserd instead.

If there is no match in the mapping, the action depends on the plugin. If a match is required, the plugin likely will return an error. Or the plugin might simply return the client name; in this case, it should not change authenticated_as, and the server will not treat the client as a proxy.

The following example demonstrates how to handle proxy users using a plugin named auth_simple_proxy. Like the auth_simple plugin described earlier, auth_simple_proxy accepts any nonempty password as valid (and thus should not be used in production environments). In addition, it examines the auth_string authentication string member and uses these very simple rules for interpreting it:

For testing, set up one account that is not proxied according to the preceding rules, and one that is. This means that one account has no AS clause, and one includes an AS clause that names the proxied user:

CREATE USER 'plugin_user1'@'localhost'  IDENTIFIED WITH auth_simple_proxy;CREATE USER 'plugin_user2'@'localhost'  IDENTIFIED WITH auth_simple_proxy AS 'proxied_user';

In addition, create an account for the proxied user and grant plugin_user2 the PROXY privilege for it:

CREATE USER 'proxied_user'@'localhost'  IDENTIFIED BY 'proxied_user_pass';GRANT PROXY  ON 'proxied_user'@'localhost'  TO 'plugin_user2'@'localhost';

Before the server invokes an authentication plugin, it sets authenticated_as to the client user name. To indicate that the user is a proxy, the plugin should set authenticated_as to the proxied user name. For auth_simple_proxy, this means that it must examine the auth_string value, and, if the value is nonempty, copy it to the authenticated_as member to return it as the name of the proxied user. In addition, when proxying occurs, the plugin sets the external_user member to the client user name; this becomes the value of the external_user system variable.

static int auth_simple_proxy_server (MYSQL_PLUGIN_VIO *vio,                                     MYSQL_SERVER_AUTH_INFO *info){  unsigned char *pkt;  int pkt_len;  /* read the password as null-terminated string, fail on error */  if ((pkt_len= vio->read_packet(vio, &pkt)) < 0)    return CR_ERROR;  /* fail on empty password */  if (!pkt_len || *pkt == '\0')  {    info->password_used= PASSWORD_USED_NO;    return CR_ERROR;  }  /* accept any nonempty password */  info->password_used= PASSWORD_USED_YES;  /* if authentication string is nonempty, use as proxied user name */  /* and use client name as external_user value */  if (info->auth_string_length > 0)  {    strcpy (info->authenticated_as, info->auth_string);    strcpy (info->external_user, info->user_name);  }  return CR_OK;}

After a successful connection, the USER() function should indicate the connecting client user and host name, and CURRENT_USER() should indicate the account whose privileges apply during the session. The latter value should be the connecting user account if no proxying occurs or the proxied account if proxying does occur.

Compile and install the plugin, then test it. First, connect as plugin_user1:

shell> mysql --user=plugin_user1
            --password=x

In this case, there should be no proxying:

mysql> SELECT USER(), CURRENT_USER(),
            @@proxy_user, @@external_user\G*************************** 1. row ***************************         USER(): plugin_user1@localhost CURRENT_USER(): plugin_user1@localhost   @@proxy_user: NULL@@external_user: NULL

Then connect as plugin_user2:

shell> mysql --user=plugin_user2
            --password=x

In this case, plugin_user2 should be proxied to proxied_user:

mysql> SELECT USER(), CURRENT_USER(),
            @@proxy_user, @@external_user\G*************************** 1. row ***************************         USER(): plugin_user2@localhost CURRENT_USER(): proxied_user@localhost   @@proxy_user: 'plugin_user2'@'localhost'@@external_user: 'plugin_user2'@'localhost'