Когда аутентификация к серверу MySQL происходит посредством плагина аутентификации, плагин может запросить, чтобы соединяющийся (внешний) пользователь был обработан как различный пользователь в проверяющих полномочие целях. Это позволяет внешнему пользователю быть прокси для второго пользователя; то есть, чтобы иметь полномочия второго пользователя. Другими словами внешний пользователь является "пользователем прокси" (пользователь, который может явиться олицетворением или стать известным как другой пользователь), и второй пользователь является "проксированным пользователем" (пользователь, идентификационные данные которого могут быть взяты пользователем прокси).

Этот раздел описывает, как пользовательская возможность прокси работает. Для получения общей информации о плагинах аутентификации, см. Раздел 6.3.7, "Сменная Аутентификация". Если Вам интересно в письменной форме Ваши собственные плагины аутентификации, которые поддерживают пользователей прокси, видят Раздел 22.2.4.9.4, "Реализовывая Пользовательскую Поддержку Прокси в Плагинах Аутентификации".

Для того, чтобы проксировать, чтобы произойти, должны быть удовлетворены эти условия:

Рассмотрите следующие определения:

CREATE USER 'empl_external'@'localhost'  IDENTIFIED WITH auth_plugin AS 'auth_string';CREATE USER 'employee'@'localhost'  IDENTIFIED BY 'employee_pass';GRANT PROXY  ON 'employee'@'localhost'  TO 'empl_external'@'localhost';

Когда клиент соединяется как empl_external от локального узла, использования MySQL auth_plugin выполнять аутентификацию. Если auth_plugin возвраты employee имя пользователя к серверу (основанный на контенте 'auth_string' и возможно консультируясь с некоторой внешней системой аутентификации), который служит запросом к серверу, чтобы обработать этот клиент, в целях проверки полномочия, как employee локальный пользователь.

В этом случае, empl_external пользователь прокси и employee проксированный пользователь.

Сервер проверяет ту аутентификацию прокси для employee возможно для empl_external пользователь, проверяя, ли empl_external имеет PROXY полномочие для employee. (Если бы это полномочие не предоставили, ошибка произошла бы.)

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

mysql> SELECT USER(), CURRENT_USER();+-------------------------+--------------------+| USER()                  | CURRENT_USER()     |+-------------------------+--------------------+| empl_external@localhost | employee@localhost |+-------------------------+--------------------+

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

Предоставление Полномочия Прокси

Специальное предложение PROXY полномочие необходимо, чтобы позволить внешнему пользователю соединиться как и иметь полномочия другого пользователя. Чтобы предоставить это полномочие, используйте GRANT оператор. Например:

GRANT PROXY ON 'proxied_user' TO 'proxy_user';

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

Соответствие REVOKE синтаксис:

REVOKE PROXY ON 'proxied_user' FROM 'proxy_user';

MySQL GRANT и REVOKE расширения синтаксиса работают как обычно. Например:

GRANT PROXY ON 'a' TO 'b', 'c', 'd';GRANT PROXY ON 'a' TO 'd' IDENTIFIED BY ...;GRANT PROXY ON 'a' TO 'd' WITH GRANT OPTION;GRANT PROXY ON 'a' TO ''@'';REVOKE PROXY ON 'a' FROM 'b', 'c', 'd';

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

PROXY полномочие можно предоставить в этих случаях:

root учетная запись, создаваемая по умолчанию во время установки MySQL, имеет PROXY ... WITH GRANT OPTION полномочие для ''@'', то есть, для всех пользователей. Это включает root устанавливать пользователей прокси, так же как делегировать к другим учетным записям полномочия, чтобы установить пользователей прокси. Например, root может сделать это:

CREATE USER 'admin'@'localhost' IDENTIFIED BY 'test';GRANT PROXY ON ''@'' TO 'admin'@'localhost' WITH GRANT OPTION;

Теперь admin пользователь может управлять всем определенным GRANT PROXY отображения. Например, admin может сделать это:

GRANT PROXY ON sally TO joe;

Пользователи Прокси значения по умолчанию

Чтобы определить, что некоторые или все пользователи должны соединить использование данного внешнего плагина, создайте "пустого" пользователя MySQL, установите его, чтобы использовать тот плагин для аутентификации, и позволить плагину возвращать вещественное число аутентифицируемое имя пользователя (если различный от пустого пользователя). Например, предположите, что там существует гипотетический названный плагин ldap_auth это реализует аутентификацию LDAP:

CREATE USER ''@'' IDENTIFIED WITH ldap_auth AS 'O=Oracle, OU=MySQL';CREATE USER 'developer'@'localhost' IDENTIFIED BY 'developer_pass';CREATE USER 'manager'@'localhost' IDENTIFIED BY 'manager_pass';GRANT PROXY ON 'manager'@'localhost' TO ''@'';GRANT PROXY ON 'developer'@'localhost' TO ''@'';

Теперь предположите, что клиент пытается соединиться следующим образом:

mysql --user=myuser --password='myuser_pass' ...

Сервер не будет находить myuser определенный как пользователь MySQL. Но потому что есть пустая учетная запись пользователя (''@''), это соответствует клиентское имя пользователя и имя хоста, сервер аутентифицирует клиент против той учетной записи: сервер вызывает ldap_auth, передача этого myuser и myuser_pass как имя пользователя и пароль.

Если ldap_auth плагин находит в каталоге LDAP это myuser_pass не корректный пароль для myuser, сбои аутентификации и сервер отклоняют соединение.

Если пароль корректен и ldap_auth находит это myuser разработчик, это возвращает имя пользователя developer к серверу MySQL, а не myuser. Сервер проверяет это ''@'' может аутентифицировать как developer (потому что это имеет PROXY полномочие сделать так), и принимает соединение. Сеанс продолжается с myuser наличие полномочий developer. (Эти полномочия должны быть установлены использованием DBA GRANT операторы, не показанные.) USER() и CURRENT_USER() функции возвращают эти значения:

mysql> SELECT USER(), CURRENT_USER();+------------------+---------------------+| USER()           | CURRENT_USER()      |+------------------+---------------------+| myuser@localhost | developer@localhost |+------------------+---------------------+

Если плагин вместо этого находит в каталоге LDAP это myuser менеджер, это возвращается manager как имя пользователя и сеанс продолжается с myuser наличие полномочий manager.

mysql> SELECT USER(), CURRENT_USER();+------------------+-------------------+| USER()           | CURRENT_USER()    |+------------------+-------------------+| myuser@localhost | manager@localhost |+------------------+-------------------+

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

Прокси значения по умолчанию считает использование '' в части узла, которая соответствует любой узел. Если Вы устанавливаете пользователя прокси значения по умолчанию, заботитесь, чтобы также проверить на учетные записи с '%' в части узла, потому что это также соответствует любой узел, но имеет приоритет '' по правилам, что сервер использует для строк учетной записи вида внутренне (см. Раздел 6.2.4, "Управление доступом, Этап 1: Проверка Соединения").

Предположите, что установка MySQL включает эти две учетных записи:

CREATE USER ''@'' IDENTIFIED WITH some_plugin;CREATE USER ''@'%' IDENTIFIED BY 'some_password';

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

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

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

Проксируйте Пользовательские Системные Переменные

Две системных справки переменных прослеживают процесс входа в систему прокси: