Настройка делегирования авторизации
В некоторых случаях, после аутентификации пользователя каким-либо доступом, мы можем делегировать поиск пользователя и назначение ролей другому доступу. Любой доступ, который поддерживает получение пользователей (без необходимости их учетных данных), может быть использован как доступом для авторизации.
Например, пользователь, аутентифицированный доступом Kerberos, может быть найден в доступе LDAP. Доступ LDAP берет на себя ответственность за поиск пользователя в LDAP и определение роли. В этом случае, доступ LDAP выступает в роли доступа для авторизации.
Доступ LDAP в качестве доступа для авторизации
Ниже приведен пример конфигурации доступа LDAP, который может быть использован в качестве доступа для авторизации. Этот доступ LDAP настроен в режиме поиска пользователей с указанным фильтром.
Дополнительную информацию о настройке доступа LDAP см. в разделе Аутентификация пользователей LDAP.
xpack:
security:
authc:
realms:
ldap:
ldap1:
order: 0
authentication.enabled: true
user_search:
base_dn: "dc=example,dc=org"
filter: "(cn={0})"
group_search:
base_dn: "dc=example,dc=org"
files:
role_mapping: "ES_PATH_CONF/role_mapping.yml"
unmapped_groups_as_roles: false | Здесь мы явно разрешаем использовать доступ LDAP для аутентификации (то есть пользователи могут аутентифицироваться с помощью своего имени пользователя и пароля LDAP). Если мы хотим, чтобы этот доступ LDAP использовался только для авторизации, то мы должны установить это значение на |
Доступ Kerberos, настроенный для делегирования авторизации
Ниже приведен пример конфигурации, где доступ Kerberos аутентифицирует пользователя, а затем делегирует авторизацию доступу LDAP. Доступ Kerberos аутентифицирует пользователя и извлекает имя принципала пользователя (обычно в формате user@REALM). В этом примере мы включаем настройку remove_realm_name, чтобы удалить часть @REALM из имени принципала пользователя, чтобы получить имя пользователя. Это имя пользователя используется для поиска пользователя с помощью настроенных доступов для авторизации (в данном случае, доступа LDAP).
Дополнительную информацию о доступе Kerberos см. в разделе Аутентификация Kerberos.
xpack:
security:
authc:
realms:
kerberos:
kerb1:
order: 1
keytab.path: "ES_PATH_CONF/es.keytab"
remove_realm_name: true
authorization_realms: ldap1 Доступ PKI, настроенный для делегирования авторизации
Аналогичным образом, мы можем настроить доступ PKI для делегирования авторизации доступу LDAP. Пользователь аутентифицируется доступом PKI, а авторизация делегируется доступу LDAP. В этом примере имя пользователя — это общее имя (CN), извлечённое из DN сертификата клиента. Доступ LDAP использует это имя пользователя для поиска пользователя и назначения роли.
Дополнительную информацию о доступе PKI см. в разделе Аутентификация PKI.
xpack:
security:
authc:
realms:
pki:
pki1:
order: 2
authorization_realms: ldap1 Аналогично вышеприведенным примерам, мы можем настроить доступы для делегирования авторизации доступам для авторизации (которые обладают возможностью поиска пользователей по имени пользователя и назначения ролей).
© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/configuring-authorization-delegation.html