Настройка единого входа SAML в Elastic Stack

Elastic Stack поддерживает профили SAML 2.0 Web Browser SSO и SAML 2.0 Single Logout и может интегрироваться с любым провайдером идентификации (IdP), поддерживающим как минимум профиль SAML 2.0 Web Browser SSO. Он протестирован с рядом популярных реализаций IdP, таких как Microsoft Active Directory Federation Services (ADFS), Azure Active Directory (AAD) и Okta.

В этом руководстве предполагается, что у вас уже есть IdP и вы хотите добавить Kibana как провайдера сервиса.

Elastic Stack использует стандартный документ метаданных SAML в формате XML, который определяет возможности и функции вашего IdP. Вы должны иметь возможность загрузить или сгенерировать такой документ в интерфейсе администрирования вашего IdP.

Загрузите документ метаданных IdP и сохраните его в каталоге config на каждом узле Elasticsearch. Для целей данного руководства мы будем считать, что вы сохраняете его как config/saml/idp-metadata.xml.

IdP будет назначен идентификатор (EntityID в терминологии SAML), который чаще всего выражается в форме Uniform Resource Identifier (URI). Интерфейс администрирования может сообщить вам об этом, или вам может потребоваться прочитать документ метаданных, чтобы найти его — найдите атрибут entityID в элементе EntityDescriptor.

Большинство IdP предоставят соответствующий файл метаданных со всеми функциями, необходимыми Elastic Stack, и потребуют только шагов по конфигурации, описанных ниже. Для полноты картины, минимальные требования Elastic Stack к метаданным IdP:

Elastic Stack требует, чтобы все сообщения от IdP были подписаны. Для аутентификации <Response> сообщений подпись может быть применена либо к самому ответу, либо к отдельным утверждениям. Для <LogoutRequest> сообщений само сообщение должно быть подписано, а подпись должна быть предоставлена в качестве параметра URL, как требуется привязкой HTTP-Redirect.

При аутентификации пользователя с помощью SAML он идентифицируется в Elastic Stack, но это не предоставляет ему автоматически доступ к выполнению действий или к данным.

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

Это пример простого сопоставления ролей, которое предоставляет роль example_role любому пользователю, аутентифицирующемуся в домене saml1:

PUT /_security/role_mapping/saml-example
{
  "roles": [ "example_role" ], 
  "enabled": true,
  "rules": {
    "field": { "realm.name": "saml1" }
  }
}

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

Поля пользователя, предоставляемые сопоставлению ролей, извлекаются из атрибутов SAML следующим образом:

Дополнительную информацию см. в разделах Сопоставление пользователей и групп с ролями и Сопоставления ролей.

Если ваш IdP может предоставлять группы или роли поставщикам услуг, вам следует сопоставить этот атрибут SAML с параметром attributes.groups в домене Elasticsearch, а затем использовать его в сопоставлении ролей, как показано в примере ниже.

Это сопоставление предоставляет роль Elasticsearch finance_data всем пользователям, которые проходят аутентификацию через домен saml1 с группой finance-team.

PUT /_security/role_mapping/saml-finance
{
  "roles": [ "finance_data" ],
  "enabled": true,
  "rules": { "all": [
        { "field": { "realm.name": "saml1" } },
        { "field": { "groups": "finance-team" } }
  ] }
}

Если ваши пользователи также существуют в хранилище, к которому Elasticsearch имеет прямой доступ (например, в каталоге LDAP), вы можете использовать домены авторизации вместо сопоставления ролей.

В этом случае выполните следующие шаги: 1. В вашем SAML домене назначьте атрибут SAML в качестве идентификатора пользователя, настроив параметр attributes.principal. 2. Создайте новый домен, который может искать пользователей из вашего локального хранилища (например, домен ldap). 3. В вашем SAML домене установите authorization_realms на имя домена, созданного на шаге 2.

По умолчанию у пользователей, аутентифицирующихся через SAML, есть дополнительные поля метаданных.

Это поведение можно отключить, добавив populate_user_metadata: false в качестве параметра в домене SAML.

Для аутентификации SAML в Kibana требуется несколько дополнительных настроек помимо стандартной конфигурации безопасности Kibana. Подробная информация о доступных параметрах конфигурации приведена в документации по безопасности Kibana.

Поскольку ваши узлы Elasticsearch настроены на использование TLS для HTTP-интерфейса, вам необходимо настроить Kibana на использование URL-адреса https для подключения к Elasticsearch, и вам может потребоваться настроить elasticsearch.ssl.certificateAuthorities для доверия сертификатам, которые были настроены для использования Elasticsearch.

Аутентификация SAML в Kibana подчиняется следующим временным ограничениям в kibana.yml:

Вы можете скорректировать эти временные ограничения в соответствии со своими требованиями к безопасности.

Три дополнительных параметра, необходимые для поддержки SAML, показаны ниже:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: "saml1"

Значения конфигурации, используемые в примере выше, следующие:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: "saml1"
  basic.basic1:
    order: 1

xpack.security.authc.realms.saml.saml_finance:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.finance.example.com/"
  sp.acs: "https://kibana.finance.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.finance.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_sales:
  order: 3
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.sales.example.com/"
  sp.acs: "https://kibana.sales.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.sales.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_eng:
  order: 4
  idp.metadata.path: saml/idp-external.xml
  idp.entity_id: "https://engineering.sso.example.net/"
  sp.entity_id:  "https://kibana.engineering.example.com/"
  sp.acs: "https://kibana.engineering.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.engineering.example.com/logout"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

Спецификация SAML 2.0 предоставляет множество вариантов и гибкости разработчикам, что, в свою очередь, повышает сложность и количество доступных параметров конфигурации как у поставщика услуг (Elastic Stack), так и у поставщика удостоверений. Кроме того, различные домены безопасности имеют различные требования к безопасности, которые требуют специфической конфигурации для удовлетворения. Были предприняты сознательные усилия для маскировки этой сложности с помощью разумных значений по умолчанию и подробной документации выше, но если у вас возникнут проблемы с настройкой домена SAML, вы можете обратиться к нашей документации по устранению неполадок SAML, где представлены рекомендации и решения для распространенных проблем.

Сфера SAML в Elasticsearch разработана для аутентификации пользователей в Kibana, и большинство разделов руководства предполагают использование Kibana. Этот раздел описывает, как пользовательское веб-приложение может использовать соответствующие REST-API SAML для аутентификации пользователей в Elasticsearch с помощью SAML.

Сферы однократного входа в систему, такие как OpenID Connect и SAML, используют службу токенов в Elasticsearch и в принципе обменивают ответ SAML или OpenID Connect на аутентификационный токен и токен обновления Elasticsearch. Токен доступа используется в качестве учетных данных для последующих обращений к Elasticsearch. Токен обновления позволяет пользователю получить новые токены доступа Elasticsearch после истечения срока действия текущего.

POST /_security/role/saml-service-role
{
  "cluster" : ["manage_saml", "manage_token"]
}

POST /_security/user/saml-service-user
{
  "password" : "<somePasswordHere>",
  "roles"    : ["saml-service-role"]
}

POST /_security/saml/authenticate
{
  "content" : "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  "ids" : []
}