8.2.17 Pluggable Authentication — MySQL 9.2

8.2.17 Подключаемая аутентификация

Когда клиент подключается к серверу MySQL, сервер использует имя пользователя, предоставленное клиентом, и хост клиента, чтобы выбрать соответствующую строку учетной записи из таблицы системы mysql.user. Затем сервер аутентифицирует клиента, определяя из строки учетной записи, какой плагин аутентификации применяется к клиенту:

Если сервер не может найти плагин, возникает ошибка, и попытка подключения отклоняется.
В противном случае сервер вызывает этот плагин для аутентификации пользователя, и плагин возвращает серверу статус, указывающий, предоставил ли пользователь правильный пароль и разрешено ли ему подключиться.

Подключаемая аутентификация обеспечивает эти важные возможности:

Выбор методов аутентификации. Подключаемая аутентификация упрощает для администраторов баз данных выбор и изменение метода аутентификации, используемого для отдельных учетных записей MySQL.
Внешняя аутентификация. Подключаемая аутентификация позволяет клиентам подключаться к серверу MySQL с учетными данными, подходящими для методов аутентификации, которые хранят учетные данные в другом месте, чем в таблице системы mysql.user. Например, могут быть созданы плагины для использования внешних методов аутентификации, таких как PAM, идентификаторы входа в Windows, LDAP или Kerberos.
Пользователи-прокси: Если пользователю разрешено подключение, плагин аутентификации может вернуть серверу имя пользователя, отличное от имени пользователя, подключающегося к серверу, чтобы указать, что подключающийся пользователь является прокси для другого пользователя (прокси-пользователя). В течение времени подключения пользователь-прокси рассматривается с точки зрения контроля доступа как обладающий привилегиями прокси-пользователя. По сути, один пользователь имитирует другого. Более подробную информацию см. в разделе 8.2.19 «Пользователи-прокси».

Примечание

Если вы запускаете сервер с параметром --skip-grant-tables, плагины аутентификации не используются, даже если они загружены, так как сервер не выполняет аутентификацию клиентов и позволяет любому клиенту подключаться. Поскольку это небезопасно, если сервер запущен с параметром --skip-grant-tables, он также отключает удалённые подключения, включив skip_networking.

Доступные плагины аутентификации

MySQL 9.2 предоставляет следующие плагины аутентификации:

Плагины, которые выполняют аутентификацию с использованием хеширования паролей SHA-256. Это более сильное шифрование, чем доступное при стандартной аутентификации. См. раздел 8.4.1.1 «Кэшируемая аутентификация SHA-2» и раздел 8.4.1.2 «Аутентификация SHA-256».
Плагин со стороны клиента, который отправляет пароль на сервер без хеширования или шифрования. Этот плагин используется совместно с плагинами на стороне сервера, которые требуют доступа к паролю в точном виде, предоставленном пользователем-клиентом. См. раздел 8.4.1.3 «Аутентификация с открытым текстом со стороны клиента».
Плагин, который выполняет внешнюю аутентификацию с помощью PAM (модули подключаемой аутентификации), позволяя серверу MySQL использовать PAM для аутентификации пользователей MySQL. Этот плагин также поддерживает пользователей-прокси. См. раздел 8.4.1.4 «Аутентификация с помощью PAM».
Плагин, выполняющий внешнюю аутентификацию в Windows, позволяя серверу MySQL использовать собственные службы Windows для аутентификации подключений клиентов. Пользователи, вошедшие в систему Windows, могут подключаться к серверу из программ-клиентов MySQL на основе информации в своей среде без указания дополнительного пароля. Этот плагин также поддерживает пользователей-прокси. См. раздел 8.4.1.5 «Аутентификация с помощью Windows».
Плагины, которые выполняют аутентификацию с помощью LDAP (протокол лёгкого доступа к каталогам) для аутентификации пользователей MySQL, обращаясь к службам каталогов, таким как X.500. Эти плагины также поддерживают пользователей-прокси. См. раздел 8.4.1.6 «Аутентификация с помощью LDAP».
Плагин, выполняющий аутентификацию с помощью Kerberos для аутентификации пользователей MySQL, соответствующих принципалам Kerberos. См. раздел 8.4.1.7 «Аутентификация с помощью Kerberos».
Плагин, выполняющий аутентификацию с использованием OpenID Connect для аутентификации пользователей MySQL. См. раздел 8.4.1.9 «Аутентификация OpenID Connect».
Плагин, который предотвращает все подключения клиентов к любой учётной записи, которая его использует. Примеры использования этого плагина включают прокси-учёные записи, которые никогда не должны допускать прямой вход, но к которым можно получить доступ только через прокси-учётные записи, и учётные записи, которые должны быть в состоянии выполнять хранимые программы и представления с повышенными привилегиями, не раскрывая эти привилегии обычным пользователям. См. раздел 8.4.1.8 «Аутентификация без входа».
Плагин, который аутентифицирует клиентов, подключающихся с локального хоста через файл Unix-соккета. См. раздел 8.4.1.10 «Аутентификация по идентификатору клиента сокета».
Плагин, который аутентифицирует пользователей на сервере MySQL с использованием формата WebAuthn с устройством FIDO/FIDO2. См. раздел 8.4.1.11 «Аутентификация WebAuthn».
Тестовый плагин, который проверяет учётные данные учётной записи и записывает результат (успех или неудачу) в журнал ошибок сервера. Этот плагин предназначен для целей тестирования и разработки и как пример написания плагина аутентификации. См. раздел 8.4.1.12 «Тестовая подключаемая аутентификация».

Примечание

Дополнительную информацию об актуальных ограничениях использования подключаемой аутентификации, включая плагины, поддерживаемые теми или иными коннекторами, см. в разделе Ограничения подключаемой аутентификации.

Разработчики сторонних коннекторов должны ознакомиться с этим разделом, чтобы определить, в какой степени коннектор может использовать возможности подключаемой аутентификации и какие шаги нужно предпринять, чтобы соответствовать требованиям.

Если вы заинтересованы в написании собственных плагинов аутентификации, см. Написание плагинов аутентификации.

Плагин проверки подлинности по умолчанию

В операторах CREATE USER и ALTER USER имеется синтаксис для указания способа проверки подлинности учетной записи. В некоторых формах этого синтаксиса имя плагина проверки подлинности не указано явно (нет никакой IDENTIFIED WITH фразы). Например:

CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';

В таких случаях сервер назначает плагин проверки подлинности по умолчанию для учетной записи. MySQL 9.2 поддерживает многофакторную аутентификацию и до трех фрагментов, определяющих способ аутентификации учетной записи. Правила, определяющие плагин проверки подлинности по умолчанию для методов проверки подлинности, в которых плагин не указан, зависят от фактора:

Фактор 1: Если элемент 1 authentication_policy указывает плагин проверки подлинности, этот плагин является плагином по умолчанию. Если элемент 1 authentication_policy равен *, то caching_sha2_password является плагином по умолчанию.

С учетом вышеизложенных правил, следующий оператор создает учетную запись с двухфакторной аутентификацией, а метод аутентификации первого фактора определяется элементом authentication_policy, как показано здесь:
```
CREATE USER 'wei'@'localhost' IDENTIFIED BY 'password'
  AND IDENTIFIED WITH authentication_ldap_simple;
```
Аналогичным образом, этот пример создает учетную запись с трехфакторной аутентификацией:
```
CREATE USER 'mateo'@'localhost' IDENTIFIED BY 'password'
  AND IDENTIFIED WITH authentication_ldap_simple
  AND IDENTIFIED WITH authentication_fido;
```
Вы можете использовать SHOW CREATE USER для просмотра применяемых методов проверки подлинности.
Фактор 2 или 3: Если соответствующий элемент authentication_policy указывает плагин проверки подлинности, этот плагин является плагином по умолчанию. Если элемент authentication_policy равен * или пуст, плагин по умолчанию отсутствует; попытка определения метода проверки подлинности учетной записи для фактора без указания плагина является ошибкой, как в следующих примерах:
```
mysql> CREATE USER 'sofia'@'localhost' IDENTIFIED WITH authentication_ldap_simple
       AND IDENTIFIED BY 'abc';
ERROR 1524 (HY000): Plugin '' is not loaded

mysql> CREATE USER 'sofia'@'localhost' IDENTIFIED WITH authentication_ldap_simple
       AND IDENTIFIED BY 'abc';
ERROR 1524 (HY000): Plugin '*' is not loaded
```

Использование плагинов проверки подлинности

В этом разделе приведены общие инструкции по установке и использованию плагинов проверки подлинности. Инструкции, специфичные для данного плагина, см. в разделе, описывающем этот плагин в разделе 8.4.1, «Плагины проверки подлинности».

В целом, плагины проверки подлинности используют пару соответствующих плагинов на серверной и клиентской сторонах, поэтому вы используете заданный метод проверки подлинности следующим образом:

При необходимости установите библиотеку(и) плагинов, содержащую(ие) необходимые плагины. На хосте сервера установите библиотеку, содержащую плагин серверной стороны, чтобы сервер мог использовать её для проверки подлинности подключений клиентов. Аналогично, на каждом хосте клиента установите библиотеку, содержащую плагин клиентской стороны для использования клиентами. Встроенные плагины проверки подлинности устанавливать не нужно.
Для каждой учетной записи MySQL, которую вы создаете, укажите соответствующий плагин серверной стороны для использования в процессе проверки подлинности. Если учетная запись должна использовать плагин проверки подлинности по умолчанию, то оператор создания учетной записи не должен явно указывать плагин. Сервер назначает плагин проверки подлинности по умолчанию, как описано в разделе «Плагин проверки подлинности по умолчанию».
При подключении клиента плагин серверной стороны сообщает клиентской программе, какой плагин клиентской стороны использовать для проверки подлинности.

В случае, если учетная запись использует метод проверки подлинности, являющийся по умолчанию как для сервера, так и для клиентской программы, серверу не нужно сообщать клиенту, какой плагин клиентской стороны использовать, и можно избежать обмена данными между клиентом и сервером.

Для стандартных клиентов MySQL, таких как mysql и mysqladmin, опция --default-auth=plugin_name может быть указана в командной строке как подсказка о том, какой плагин клиентской стороны может использовать программа, хотя сервер переопределяет это, если плагин серверной стороны, связанный с учетной записью пользователя, требует другого плагина клиентской стороны.

Если клиентская программа не находит файл библиотеки плагина клиентской стороны, укажите опцию --plugin-dir=dir_name для указания расположения каталога библиотеки плагинов.

Совместимость плагинов проверки подлинности на стороне клиента и сервера

Плагины проверки подлинности обеспечивают гибкость в выборе методов проверки подлинности для учетных записей MySQL, но в некоторых случаях подключение клиентов не может быть установлено из-за несовместимости плагинов проверки подлинности между клиентом и сервером.

Общим принципом совместимости для успешного подключения клиента к данной учетной записи на данном сервере является то, что клиент и сервер должны оба поддерживать метод проверки подлинности, требуемый учетной записью. Поскольку методы проверки подлинности реализуются плагинами проверки подлинности, клиент и сервер должны оба поддерживать плагин проверки подлинности, требуемый учетной записью.

Несовместимости плагинов проверки подлинности могут возникать по разным причинам. Примеры:

Подключение с помощью клиентской программы MySQL 5.7 версии 5.7.22 или ниже к серверной учетной записи MySQL 9.2, которая использует caching_sha2_password. Это не удается, потому что клиент 5.7 не распознает плагин. (Эта проблема решена в MySQL 5.7 начиная с версии 5.7.23, когда caching_sha2_password поддержка клиентской стороны была добавлена в библиотеку клиентской программы MySQL и в клиентские программы.)
Подключение с помощью клиентской программы MySQL 5.7 к учетной записи сервера до версии 5.7, которая использует mysql_old_password. Это не удается по нескольким причинам. Во-первых, для такого подключения требуется --secure-auth=0, что больше не является поддерживаемой опцией. Даже если бы это поддерживалось, клиент 5.7 не распознает плагин, потому что он был удалён в MySQL 5.7.
Подключение с помощью клиентской программы MySQL 5.7 из дистрибутива Community к серверу MySQL 5.7 Enterprise с учетной записью, использующей один из плагинов проверки подлинности LDAP, доступных только в Enterprise. Это не удается, так как клиент Community не имеет доступа к плагину Enterprise.

В общем случае эти проблемы совместимости не возникают при подключении между клиентом и сервером из одного и того же дистрибутива MySQL. При подключениях между клиентом и сервером из разных серий MySQL могут возникнуть проблемы. Эти проблемы присущи процессу разработки, когда MySQL вводит новые плагины проверки подлинности или удаляет старые. Чтобы свести к минимуму вероятность несовместимостей, регулярно обновляйте сервер, клиенты и соединители своевременно.

Учитываемые моменты при написании соединителей для плагинов проверки подлинности

Существуют различные реализации протокола MySQL клиент/сервер. Библиотека API клиента libmysqlclient C является одной из них. Некоторые соединители MySQL (обычно те, которые не написаны на C) предоставляют собственную реализацию. Однако не все реализации протокола обрабатывают проверку подлинности плагинов одинаково. В этом разделе описывается проблема проверки подлинности, которую должны учитывать разработчики протоколов.

В протоколе клиент/сервер сервер сообщает подключающимся клиентам, какой плагин проверки подлинности он считает по умолчанию. Если реализация протокола, используемая клиентом, пытается загрузить плагин по умолчанию, а этот плагин отсутствует на клиентской стороне, операция загрузки завершается ошибкой. Это ненужная ошибка, если плагин по умолчанию не является плагином, фактически требуемым учетной записью, к которой пытается подключиться клиент.

Если реализация протокола клиент/сервер не имеет собственного понятия плагина проверки подлинности по умолчанию и всегда пытается загрузить плагин по умолчанию, указанный сервером, она завершается с ошибкой, если этот плагин недоступен.

Чтобы избежать этой проблемы, реализация протокола, используемая клиентом, должна иметь свой собственный плагин по умолчанию и использовать его в качестве первого варианта (или, как альтернатива, откатываться к этому варианту в случае невозможности загрузки плагина по умолчанию, указанного сервером). Пример:

В MySQL 5.7, libmysqlclient использует в качестве своего выбора либо mysql_native_password, либо плагин, указанный с помощью опции MYSQL_DEFAULT_AUTH для .
Когда клиент 5.7 пытается подключиться к серверу 9.2, сервер указывает caching_sha2_password в качестве плагина проверки подлинности по умолчанию, но клиент всё равно отправляет данные учетных данных по mysql_native_password или по тому, что указано с помощью MYSQL_DEFAULT_AUTH.
Единственный случай, когда клиент загружает плагин, указанный сервером, — это запрос на изменение плагина, но в этом случае это может быть любой плагин в зависимости от учетной записи пользователя. В этом случае клиент должен попытаться загрузить плагин, и если этот плагин недоступен, ошибка не является необязательной.

END_OF_DOCUMENT_MARKER

Ограничения для подключаемой аутентификации

В первой части этого раздела описываются общие ограничения на применение подключаемой системы аутентификации, описанной в разделе 8.2.17, «Подключаемая аутентификация». Во второй части описывается, как разработчики сторонних коннекторов могут определить степень, в которой коннектор может использовать возможности подключаемой аутентификации, и какие шаги необходимо предпринять для повышения соответствия.

Здесь термин “собственная аутентификация” относится к аутентификации по паролям, хранящимся в таблице системы mysql.user. Это тот же метод аутентификации, который предоставляют старые серверы MySQL до внедрения подключаемой аутентификации. “Встроенная аутентификация Windows” относится к аутентификации с использованием учетных данных пользователя, уже вошедшего в Windows, как реализовано в плагине Windows Native Authentication (“плагин Windows” для краткости).

Общие ограничения подключаемой аутентификации

Connector/C++: Клиенты, использующие этот коннектор, могут подключаться к серверу только через учетные записи, использующие собственную аутентификацию.

Исключение: коннектор поддерживает подключаемую аутентификацию, если он был разработан для динамической (а не статической) связи с libmysqlclient и загружает текущую версию libmysqlclient, если она установлена, или если коннектор перекомпилирован из исходного кода для связи с текущей libmysqlclient.

Дополнительная информация о написании коннекторов для обработки информации от сервера о стандартном серверном плагине аутентификации находится в Учитываемые моменты при разработке коннекторов для плагинов аутентификации.
Connector/NET: Клиенты, использующие Connector/NET, могут подключаться к серверу через учетные записи, использующие собственную аутентификацию или встроенную аутентификацию Windows.
Connector/PHP: Клиенты, использующие этот коннектор, могут подключаться к серверу только через учетные записи, использующие собственную аутентификацию, при компиляции с использованием родного драйвера MySQL для PHP (mysqlnd).
Встроенная аутентификация Windows: Подключение через учетную запись, использующую плагин Windows, требует настройки домена Windows. Без нее используется аутентификация NTLM, и возможны только локальные подключения; то есть, клиент и сервер должны работать на одном компьютере.
Пользователи-прокси: Поддержка пользователей-прокси доступна в той мере, в которой клиенты могут подключаться через учетные записи, аутентифицированные с помощью плагинов, реализующих возможность пользователя-прокси (то есть плагинов, которые могут возвращать имя пользователя, отличное от имени подключившегося пользователя). Например, плагины PAM и Windows поддерживают пользователей-прокси. Плагин аутентификации sha256_password по умолчанию не поддерживает пользователей-прокси, но может быть настроен на это; см. Поддержка сервера для сопоставления пользователей-прокси.
Репликация: Реплики могут не только использовать учетные записи репликации с использованием собственной аутентификации, но и подключаться через учетные записи репликации, использующие несобственную аутентификацию, если доступен необходимый плагин на стороне клиента. Если плагин встроен в libmysqlclient, он доступен по умолчанию. В противном случае плагин должен быть установлен на стороне реплики в каталоге, указанном переменной системы реплики plugin_dir.
FEDERATED таблицы: Таблица FEDERATED может получить доступ к удаленной таблице только через учетные записи на удаленном сервере, использующие собственную аутентификацию.

Подключаемая аутентификация и сторонние коннекторы

Разработчики сторонних коннекторов могут использовать следующие рекомендации для определения готовности коннектора к использованию возможностей подключаемой аутентификации и шагов для повышения соответствия:

Существующий коннектор, к которому не были внесены изменения, использует собственную аутентификацию, и клиенты, использующие этот коннектор, могут подключаться к серверу только через учетные записи, использующие собственную аутентификацию. Однако вы должны протестировать коннектор на последней версии сервера, чтобы убедиться, что такие подключения по-прежнему работают без проблем.

Исключение: коннектор может работать с подключаемой аутентификацией без изменений, если он связан с libmysqlclient динамически (а не статически) и загружает текущую версию libmysqlclient, если она установлена.
Для использования возможностей подключаемой аутентификации коннектор, основанный на libmysqlclient, должен быть пересоединен с текущей версией libmysqlclient. Это позволит коннектору поддерживать подключения через учетные записи, требующие плагинов на стороне клиента, которые сейчас встроен в libmysqlclient (например, плагин cleartext, необходимый для аутентификации PAM, и плагин Windows, необходимый для встроенной аутентификации Windows). Связывание с текущей libmysqlclient также позволит коннектору получить доступ к плагинам на стороне клиента, установленным в стандартном каталоге плагинов MySQL (обычно каталог, указанный значением по умолчанию переменной системы локального сервера plugin_dir).

Если коннектор связан с libmysqlclient динамически, необходимо убедиться, что на хосте клиента установлена более новая версия libmysqlclient и что коннектор загружает ее во время выполнения.
Другой способ для коннектора поддержать определенный метод аутентификации заключается в его прямой реализации в протоколе клиент/сервер. Connector/NET использует этот подход для обеспечения поддержки встроенной аутентификации Windows.
Если коннектору необходимо загружать плагины на стороне клиента из каталога, отличного от стандартного каталога плагинов, он должен реализовать способ для пользователей клиента указать этот каталог. Возможности для этого включают опцию командной строки или переменную среды, из которой коннектор может получить имя каталога. Стандартные программы клиентов MySQL, такие как mysql и mysqladmin, реализуют опцию --plugin-dir. См. также .
Поддержка пользователей-прокси коннектором зависит, как описано ранее в этом разделе, от того, допускают ли поддерживаемые им методы аутентификации пользователей-прокси.