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

Механизм проксирования позволяет сопоставлять только имя внешнего пользователя-клиента с именем проксируемого пользователя. Нет возможности сопоставления имён хостов:

Рассмотрим следующие определения учётных записей:

-- create proxy account
CREATE USER 'employee_ext'@'localhost'
  IDENTIFIED WITH my_auth_plugin
  AS 'my_auth_string';

-- create proxied account and grant its privileges;
-- use mysql_no_login plugin to prevent direct login
CREATE USER 'employee'@'localhost'
  IDENTIFIED WITH mysql_no_login;
GRANT ALL
  ON employees.*
  TO 'employee'@'localhost';

-- grant to proxy account the
-- PROXY privilege for proxied account
GRANT PROXY
  ON 'employee'@'localhost'
  TO 'employee_ext'@'localhost';

Когда клиент подключается как employee_ext с локального хоста, MySQL использует плагин, названный my_auth_plugin, для выполнения аутентификации. Предположим, что my_auth_plugin возвращает имя пользователя employee серверу, основываясь на содержимом 'my_auth_string' и, возможно, консультируясь с какой-либо внешней системой аутентификации. Имя employee отличается от employee_ext, поэтому возвращение employee служит запросом к серверу рассматривать внешнего пользователя employee_ext, в целях проверки привилегий, как локального пользователя employee.

В этом случае employee_ext является пользователем-прокси, а employee — проксируемым пользователем.

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

Учётная запись проксируемого пользователя, employee, использует плагин аутентификации mysql_no_login, чтобы предотвратить подключение клиентов напрямую к этой учётной записи. (Это предполагает, что плагин установлен. Для инструкций см. Раздел 8.4.1.9, «Плагин аутентификации без входа»). Для альтернативных методов защиты проксируемых учётных записей от прямого использования см. Предотвращение прямого входа в проксируемые учётные записи.

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

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

В операторе CREATE USER, создающем учётную запись пользователя-прокси, за предложением IDENTIFIED WITH, указывающим поддерживающий прокси-плагин, необязательно следует предложение AS 'auth_string', которое указывает строку, передаваемую сервером плагину при подключении пользователя. При наличии, эта строка предоставляет информацию, которая помогает плагину определить, как сопоставить имя пользователя прокси-клиента (внешнего) с именем проксируемого пользователя. Каждый плагин сам решает, требуется ли ему предложение AS. Если это необходимо, формат строки аутентификации зависит от того, как плагин планирует её использовать. Обратитесь к документации конкретного плагина за информацией о значениях строки аутентификации, которые он принимает.

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

Существует несколько способов гарантировать, что проксированная учетная запись не может использоваться напрямую:

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

GRANT PROXY ON 'proxied_user' TO 'proxy_user';

Оператор создаёт строку в таблице предоставления mysql.proxies_priv.

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

Соответствующий синтаксис оператора REVOKE:

REVOKE PROXY ON 'proxied_user' FROM 'proxy_user';

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

-- grant PROXY to multiple accounts
GRANT PROXY ON 'a' TO 'b', 'c', 'd';

-- revoke PROXY from multiple accounts
REVOKE PROXY ON 'a' FROM 'b', 'c', 'd';

-- grant PROXY to an account and enable the account to grant
-- PROXY to the proxied account
GRANT PROXY ON 'a' TO 'd' WITH GRANT OPTION;

-- grant PROXY to default proxy account
GRANT PROXY ON 'a' TO ''@'';

Привилегия PROXY может быть предоставлена в следующих случаях:

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

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

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

GRANT PROXY ON sally TO joe;

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

-- create default proxy account
CREATE USER ''@''
  IDENTIFIED WITH ldap_auth
  AS 'O=Oracle, OU=MySQL';

-- create proxied accounts; use
-- mysql_no_login plugin to prevent direct login
CREATE USER 'developer'@'localhost'
  IDENTIFIED WITH mysql_no_login;
CREATE USER 'manager'@'localhost'
  IDENTIFIED WITH mysql_no_login;

-- grant to default proxy account the
-- PROXY privilege for proxied accounts
GRANT PROXY
  ON 'manager'@'localhost'
  TO ''@'';
GRANT PROXY
  ON 'developer'@'localhost'
  TO ''@'';

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

$> mysql --user=myuser --password ...
Enter password: myuser_password

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

Если плагин ldap_auth найдет в каталоге LDAP, что myuser_password не является правильным паролем для myuser, аутентификация завершается неудачей, и сервер отклоняет подключение.

Если пароль правильный, и ldap_auth обнаружит, что myuser — разработчик, он возвращает имя пользователя developer серверу MySQL вместо myuser. Возврат имени пользователя, отличного от имени пользователя клиента myuser, сигнализирует серверу о том, что он должен рассматривать myuser как прокси. Сервер проверяет, что ''@'' может авторизоваться как developer (потому что у ''@'' есть привилегия PROXY для этого) и принимает подключение. Сеанс продолжается с myuser, имеющим привилегии проксированного пользователя developer. (Эти привилегии должны быть настроены администратором базы данных с помощью операторов 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, поэтому эти проксированные учетные записи должны быть защищены от прямого входа (см. Предотвращение прямого входа в проксированные учетные записи).

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

В предыдущем обсуждении учетная запись пользователя-прокси по умолчанию имеет '' в части хоста, что соответствует любому хосту. Если вы настроите пользователя-прокси по умолчанию, позаботьтесь о проверке существования учетных записей без прокси с той же частью пользователя и '%' в части хоста, поскольку '%' также соответствует любому хосту, но имеет приоритет над '' по правилам, которые сервер использует для сортировки строк учетных записей внутри (см. Раздел 8.2.6, «Управление доступом, этап 1: Проверка подключения»).

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

-- create default proxy account
CREATE USER ''@''
  IDENTIFIED WITH some_plugin
  AS 'some_auth_string';
-- create anonymous account
CREATE USER ''@'%'
  IDENTIFIED BY 'anon_user_password';

Первая учетная запись (''@'') предназначена в качестве пользователя-прокси по умолчанию, используемого для проверки подлинности подключений для пользователей, которые иначе не соответствуют более конкретной учетной записи. Вторая учетная запись (''@'%') — это учетная запись анонимного пользователя, которая могла быть создана, например, для обеспечения возможности подключения анонимно пользователям без собственной учетной записи.

Обе учетные записи имеют одинаковую часть пользователя (''), которая соответствует любому пользователю. И каждая учетная запись имеет часть хоста, которая соответствует любому хосту. Тем не менее, существует приоритет в соответствии с учетными записями для попыток подключения, поскольку правила соответствия сортируют хост '%' перед ''. Для учетных записей, которые не соответствуют более конкретной учетной записи, сервер пытается выполнить проверку подлинности по отношению к ''@'%' (анонимному пользователю), а не к ''@'' (пользователю-прокси по умолчанию). В результате учетная запись пользователя-прокси по умолчанию никогда не используется.

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

Некоторые плагины аутентификации реализуют сопоставление пользователей-прокси для себя (например, плагины аутентификации PAM и Windows). Другие плагины аутентификации по умолчанию не поддерживают пользователей-прокси. Из них некоторые могут запросить, чтобы сам сервер MySQL сопоставил пользователей-прокси в соответствии с предоставленными привилегиями прокси: mysql_native_password (устарело), sha256_password (устарело). Если системная переменная check_proxy_users включена, сервер выполняет сопоставление пользователей-прокси для любых плагинов аутентификации, которые делают такой запрос:

Например, чтобы включить все вышеперечисленные возможности, запустите сервер со следующими строками в файле my.cnf:

[mysqld]
check_proxy_users=ON
mysql_native_password_proxy_users=ON
sha256_password_proxy_users=ON

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

-- create proxy account
CREATE USER 'proxy_user'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'password';

-- create proxied account and grant its privileges;
-- use mysql_no_login plugin to prevent direct login
CREATE USER 'proxied_user'@'localhost'
  IDENTIFIED WITH mysql_no_login;
-- grant privileges to proxied account
GRANT ...
  ON ...
  TO 'proxied_user'@'localhost';

-- grant to proxy account the
-- PROXY privilege for proxied account
GRANT PROXY
  ON 'proxied_user'@'localhost'
  TO 'proxy_user'@'localhost';

Для использования учетной записи-прокси подключитесь к серверу с ее именем и паролем:

$> mysql -u proxy_user -p
Enter password: (enter proxy_user password here)

Проверка подлинности успешна, сервер обнаруживает, что proxy_user имеет привилегию PROXY для proxied_user, и сеанс продолжается с proxy_user, имеющим привилегии proxied_user.

Сопоставление пользователей-прокси, выполняемое сервером, ограничено следующими правилами:

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