#validation #saml #trust
#проверка #saml #доверие
Вопрос:
Я пытаюсь внедрить поставщика услуг SAML, чтобы разрешить единый вход для облачного приложения, в этом приложении может размещаться несколько клиентов или компаний. Обычно пользователь вводит адрес электронной почты (который выступает в качестве идентификатора пользователя) и пароль для входа в систему (клиент будет идентифицирован с помощью параметра URL).
Полученное утверждение SAML имеет сертификат X509, встроенный в полезную нагрузку, который используется для проверки подписи SAML. Хотя подпись может использоваться для проверки правильности утверждения, есть опасения, что кто-то, кроме поставщика удостоверений, может сгенерировать свои собственные открытые / закрытые ключи, подписать свое собственное утверждение с правильно «угаданным» действительным идентификатором клиента и адресом электронной почты пользователя, а затем потенциально получить доступ к приложению.
Какой механизм или метод используется для определения того, что утверждение и его встроенный сертификат получены от определенного поставщика удостоверений, отличного от информации, содержащейся в полезной нагрузке SAML? Хотя я читал, что сертификаты можно загружать у поставщиков удостоверений, есть опасения, что срок действия этих сертификатов истечет или они будут отозваны, и, кроме того, нам также придется хранить их на нашей стороне. Существует законное опасение, что эти сценарии приведут к простою пользователей.
Еще один небольшой вопрос: поскольку нам требуется идентификатор клиента, чтобы определить, какой клиент подписывается на конкретную учетную запись пользователя, обычно ли (или правильно) указывать этот идентификатор через URI, например, в URL-адресе или в качестве параметра на нашей конечной точке, получающей утверждение SAML?
Ответ №1:
Доверие SAML
Когда вы внедряете свой SP SAML, вам будет предложено предварительно настроить сертификат подписи вашего целевого IdP SAML. Поэтому ваш SP будет доверять только любым входящим утверждениям, подписанным этим конкретным сертификатом подписи.
Конфигурация SAML
Настройка SAML SP может быть выполнена путем настройки всех параметров IdP, включая сертификат подписи вручную, или путем указания файла метаданных, который содержит все параметры IdP, включая сертификат подписи.
Вы можете загрузить файл метаданных из IdP и использовать его локально в своем SP SAML или указать URL-адрес файла метаданных и разрешить SP SAML загружать и использовать его.
В качестве примера вы можете сослаться на URL-адрес метаданных SAML Azure AD: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
Очевидно, что этот URL-адрес должен быть защищен TLS / SSL, и его содержимое должно быть изменено только IdP.
Ротация сертификатов подписи SAML
При замене сертификата подписи доверие между IdP и SP теряется. Вам нужно будет повторно настроить свой SP, чтобы доверять новому сертификату напрямую или обновлять файл метаданных.
Если вы решите настроить свой SP SAML, указав URL-адрес метаданных IdP, вы можете рассмотреть возможность настройки библиотеки SP SAML для регулярной загрузки и обновления метаданных из IdP.
Таким образом, ваш SP SAML будет иметь надежный способ проверки последнего сертификата подписи, даже если сертификат может быть изменен.
Комментарии:
1. Это чрезвычайно полезно. Мне нужно было определить, какую дополнительную информацию мне нужно сохранить (в данном случае URL-адрес IdP для получения метаданных сертификата) и что может потребоваться сделать, когда сертификат IdP отозван или истек. Спасибо!