Общие проблемы SAML
Ниже приведены некоторые распространённые проблемы SAML с советами по их решению.
-
Симптомы:
Авторизация в 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. -
Симптомы:
Авторизация в 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-адреса. Обращайте внимание на конечные слэши, номера портов и т. д.
-
Симптомы:
Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:
Cannot find metadata for entity [your:entity.id] in [metadata.xml]
Решение:
Не удалось найти метаданные для идентификатора субъекта SAML
your:entity.idв файле настроенных метаданных (metadata.xml).- Убедитесь, что используемый вами файл
metadata.xml— это именно тот, который предоставил ваш поставщик идентификации SAML. - Убедитесь, что файл
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. - Обратите внимание, что эти строки также сравниваются как чувствительные к регистру строки, а не как канонизированные URL-адреса, даже если значения похожи на URL-адреса.
- Убедитесь, что используемый вами файл
-
Симптомы:
Авторизация в Kibana не удаётся, и в журналы Elasticsearch выводится следующая ошибка:
unable to authenticate user [<unauthenticated-saml-user>] for action [cluster:admin/xpack/security/saml/authenticate]
Решение:
Эта ошибка указывает на то, что Elasticsearch не смог обработать входящее сообщение об аутентификации SAML. Так как сообщение не может быть обработано, Elasticsearch не знает, кто является авторизуемым пользователем, и вместо этого используется
<unauthenticated-saml-user>. Для диагностики фактической проблемы необходимо проверить журналы Elasticsearch на наличие дополнительных подробностей. -
Симптомы:
Авторизация в 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 для определения, можно ли отправить требуемый атрибут. -
Симптомы:
Авторизация в 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. -
Симптомы:
Авторизация в 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, а наиболее часто встречающиеся из них:
-
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed: Поставщик идентификации SAML не смог аутентифицировать пользователя. Для устранения неполадок со стороны Elastic Stack в этом случае можно сделать немного, но журналы поставщика идентификации SAML, надеюсь, предоставят больше информации. -
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, чтобы поставщик идентификации мог вернуть любой формат.
-
-
Симптомы:
Авторизация в 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 с использованием соответствующего закрытого ключа. Невозможность этого может иметь ряд причин:
- Как указывает сообщение об ошибке, наиболее распространённой причиной является использование неправильного файла метаданных, в связи с чем открытый ключ в нём не соответствует закрытому ключу, используемому поставщиком идентификации.
- Конфигурация поставщика идентификации изменилась или ключ был обновлён, а файл метаданных, используемый Elasticsearch, не был обновлён.
- Сообщение SAML Response было изменено во время передачи, и подпись не может быть проверена, даже если используется правильный ключ.
Закрытые и открытые ключи и самоподписанные сертификаты X.509, используемые в SAML для цифровых подписей, как описано выше, не имеют отношения к ключам и сертификатам, используемым для TLS ни в транспортном, ни в http-слоях. Ошибка, описанная выше, не связана с вашей конфигурацией, связанной с
xpack.ssl. -
Симптомы:
Пользователи не могут войти с локальным именем пользователя и паролем в Kibana, потому что SAML включён.
Решение:
Если вы хотите, чтобы ваши пользователи могли использовать локальные учетные данные для входа в Kibana помимо использования домена SAML для единого входа, необходимо включить
basicauthProviderв Kibana. Процесс описан в Руководстве по SAML.
-
Симптомы:
Из 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