Spec-Zone.ru › Elasticsearch 8
›Elasticsearch Guide [8.17] ›Обеспечение безопасности Elastic Stack ›Поиск и устранение неполадок безопасности

Общие проблемы SAML

Ниже приведены некоторые распространённые проблемы SAML с советами по их решению.

  1. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=saml1,
    assertionConsumerServiceURL=https://my.kibana.url/api/security/saml/callback}]

    Решение:

    Для инициирования аутентификации SAML Kibana должна знать, какой домен SAML использовать из настроенных в Elasticsearch. Можно использовать настройку xpack.security.authc.providers.saml.<provider-name>.realm для явного указания имени домена SAML в Kibana. Оно должно совпадать с именем домена SAML, настроенного в Elasticsearch.

    Если появляется ошибка, подобная описанной выше, возможно, неправильно указано значение xpack.security.authc.providers.saml.<provider-name>.realm в вашей конфигурации Kibana. Проверьте, что оно совпадает с именем настроенного домена в Elasticsearch, которое представляет собой строку после xpack.security.authc.realms.saml. в вашей конфигурации Elasticsearch.

  2. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Authentication to realm saml1 failed - Provided SAML response is not valid for realm
    saml/saml1 (Caused by ElasticsearchSecurityException[Conditions
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company....ple.com/]
    do not match required audience
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]])

    Решение:

    Получен ответ SAML, адресованный другому поставщику SAML-услуг. Это обычно означает, что настроенный идентификатор субъекта поставщика SAML-услуг в elasticsearch.yml (sp.entity_id) не совпадает с тем, что настроено как идентификатор субъекта поставщика SAML-услуг в документации поставщика идентификации.

    Для решения этой проблемы убедитесь, что как домен saml в Elasticsearch, так и IdP настроены с одинаковой строкой для идентификатора субъекта поставщика SAML-услуг.

    В журнале Elasticsearch, непосредственно перед сообщением об ошибке (выше), также будет одно или несколько сообщений уровня INFO вида

    Audience restriction
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com/]
    does not match required audience
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]
    (difference starts at character [#68] [/] vs [])

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

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

  3. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Cannot find metadata for entity [your:entity.id] in [metadata.xml]

    Решение:

    Не удалось найти метаданные для идентификатора субъекта SAML your:entity.id в файле настроенных метаданных (metadata.xml).

    1. Убедитесь, что используемый вами файл metadata.xml — это именно тот, который предоставил ваш поставщик идентификации SAML.
    2. Убедитесь, что файл metadata.xml содержит один элемент <EntityDescriptor> в следующем формате: <EntityDescriptor ID="0597c9aa-e69b-46e7-a1c6-636c7b8a8070" entityID="https://saml.example.com/f174199a-a96e-4201-88f1-0d57a610c522/" ..., где значение атрибута entityID совпадает со значением атрибута idp.entity_id, которое вы задали в конфигурации домена SAML в elasticsearch.yml.
    3. Обратите внимание, что эти строки также сравниваются как чувствительные к регистру строки, а не как канонизированные URL-адреса, даже если значения похожи на URL-адреса.
  4. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    unable to authenticate user [<unauthenticated-saml-user>]
    for action [cluster:admin/xpack/security/saml/authenticate]

    Решение:

    Эта ошибка указывает на то, что Elasticsearch не смог обработать входящее сообщение об аутентификации SAML. Так как сообщение не может быть обработано, Elasticsearch не знает, кто является авторизуемым пользователем, и вместо этого используется <unauthenticated-saml-user>. Для диагностики фактической проблемы необходимо проверить журналы Elasticsearch на наличие дополнительных подробностей.

  5. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Authentication to realm <saml-realm-name> failed - SAML Attribute [<AttributeName0>] for
    [xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal] not found in saml attributes
    [<AttributeName1>=<AttributeValue1>, <AttributeName2>=<AttributeValue2>, ...] or NameID [ NameID(format)=value ]

    Решение:

    Эта ошибка указывает на то, что Elasticsearch не смог найти необходимый атрибут SAML в ответе SAML, отправленном поставщиком идентификации. В этом примере Elasticsearch настроен следующим образом:

    xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal: AttributeName0

    Эта конфигурация означает, что Elasticsearch ожидает найти атрибут SAML с именем AttributeName0 или NameID с соответствующим форматом в ответе SAML, чтобы отобразить его на свойство пользователя principal. Свойство пользователя principal является обязательным, поэтому если такое отображение не происходит, аутентификация завершается неудачей.

    Если вы пытаетесь отобразить NameID, убедитесь, что ожидаемый формат NameID соответствует отправленному. См. Специальные имена атрибутов для получения дополнительных сведений.

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

  6. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Cannot find [{urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor]/[urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect] in descriptor

    Решение:

    Эта ошибка указывает на то, что метаданные SAML для вашего поставщика идентификации не содержат конечную точку <SingleSignOnService> с типом связи HTTP-Redirect (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect). Elasticsearch поддерживает только тип связи HTTP-Redirect для запросов аутентификации SAML (и не поддерживает тип связи HTTP-POST). Обратитесь к администратору IdP, чтобы включить хотя бы одну конечную точку <SingleSignOnService>, поддерживающую тип связи HTTP-Redirect, и обновите метаданные IdP SAML.

  7. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    Authentication to realm my-saml-realm failed -
    Provided SAML response is not valid for realm saml/my-saml-realm
    (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response:
     The SAML IdP did not grant the request. It indicated that the Elastic Stack side sent
     something invalid (urn:oasis:names:tc:SAML:2.0:status:Requester). Specific status code which might
     indicate what the issue is: [urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy]]
    )

    Решение:

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

    1. urn:oasis:names:tc:SAML:2.0:status:AuthnFailed: Поставщик идентификации SAML не смог аутентифицировать пользователя. Для устранения неполадок со стороны Elastic Stack в этом случае можно сделать немного, но журналы поставщика идентификации SAML, надеюсь, предоставят больше информации.
    2. urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy: Поставщик идентификации SAML не может предоставить NameID с запрошенным форматом. При создании запросов аутентификации SAML Elasticsearch задаёт элемент NameIDPolicy запроса аутентификации с соответствующим значением. Это контролируется параметром конфигурации nameid_format в elasticsearch.yml, который по умолчанию равен urn:oasis:names:tc:SAML:2.0:nameid-format:transient. Это инструктирует поставщика идентификации вернуть NameID с этим конкретным форматом в ответе SAML. Если поставщик идентификации SAML не может выполнить этот запрос, например, если он настроен на выпуск NameID с форматом urn:oasis:names:tc:SAML:2.0:nameid-format:persistent вместо этого, он возвращает эту ошибку, указывая на недействительную политику NameID. Проблему можно решить, скорректировав значение nameid_format для соответствия формату, который может вернуть поставщик идентификации SAML, или установив его в значение urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified, чтобы поставщик идентификации мог вернуть любой формат.
  8. Симптомы:

    Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:

    The XML Signature of this SAML message cannot be validated. Please verify that the saml
    realm uses the correct SAMLmetadata file/URL for this Identity Provider

    Решение:

    Это означает, что Elasticsearch не смог проверить цифровую подпись сообщения SAML, отправленного поставщиком идентификации. Elasticsearch использует открытый ключ поставщика идентификации, который содержится в метаданных SAML, для проверки подписи, созданной IdP с использованием соответствующего закрытого ключа. Невозможность этого может иметь ряд причин:

    1. Как указывает сообщение об ошибке, наиболее распространённой причиной является использование неправильного файла метаданных, в связи с чем открытый ключ в нём не соответствует закрытому ключу, используемому поставщиком идентификации.
    2. Конфигурация поставщика идентификации изменилась или ключ был обновлён, а файл метаданных, используемый Elasticsearch, не был обновлён.
    3. Сообщение SAML Response было изменено во время передачи, и подпись не может быть проверена, даже если используется правильный ключ.

    Закрытые и открытые ключи и самоподписанные сертификаты X.509, используемые в SAML для цифровых подписей, как описано выше, не имеют отношения к ключам и сертификатам, используемым для TLS ни в транспортном, ни в http-слоях. Ошибка, описанная выше, не связана с вашей конфигурацией, связанной с xpack.ssl.

  9. Симптомы:

    Пользователи не могут войти с локальным именем пользователя и паролем в Kibana, потому что SAML включён.

    Решение:

    Если вы хотите, чтобы ваши пользователи могли использовать локальные учетные данные для входа в Kibana помимо использования домена SAML для единого входа, необходимо включить basic authProvider в Kibana. Процесс описан в Руководстве по SAML.

  1. Симптомы:

    Из Kibana в Elasticsearch не передаются значения идентификаторов запросов SAML:

    Caused by org.elasticsearch.ElasticsearchSecurityException: SAML content is in-response-to [_A1B2C3D4E5F6G8H9I0] but expected one of []

    Решение: Эта ошибка указывает на то, что Elasticsearch получил ответ SAML, связанный с определённым запросом SAML, но Kibana не указал явно идентификатор этого запроса. Это обычно означает, что Kibana не может найти сеанс пользователя, в котором ранее хранился идентификатор запроса SAML.

    Для решения этой проблемы убедитесь, что в вашей конфигурации Kibana xpack.security.sameSiteCookies не установлено в Strict. В зависимости от вашей конфигурации, вы можете полагаться на значение по умолчанию или явно установить значение в None.

    Для получения дополнительной информации, пожалуйста, ознакомьтесь со статьёй MDN SameSite cookie

    Если вы обслуживаете несколько установок Kibana через балансировщик нагрузки, убедитесь, что для всех установок используется одинаковая конфигурация безопасности.

Ведение журнала:

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

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
    },
)
print(resp)
response = client.cluster.put_settings(
  body: {
    persistent: {
      'logger.org.elasticsearch.xpack.security.authc.saml' => 'debug'
    }
  }
)
puts response
const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.xpack.security.authc.saml": "debug",
  },
});
console.log(response);
PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
  }
}

В качестве альтернативы, вы можете добавить следующие строки в конец файла конфигурации log4j2.properties в папке ES_PATH_CONF:

logger.saml.name = org.elasticsearch.xpack.security.authc.saml
logger.saml.level = DEBUG

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

© 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/8.17/trb-security-saml.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API