Блог

Главная - Вопросы по программированию - SAML SP: Доверяйте сертификату ВПЛ

SAML SP: Доверяйте сертификату ВПЛ

#xml #saml #saml-2.0 #simplesamlphp

Вопрос:

Я ИП и хочу проверить подписи от ВПЛ. ВПЛ сказал мне, что наш ИП не доверяет сертификату ВПЛ.

Насколько я понимаю, это происходит:

 SP-> SAML request digitally signed with private key of SP
IdP-> SAML request gets verified with public key of SP (from metadata)

IdP-> SAML response signed with private key of IdP
SP-> SAML response gets verified with public key of IdP (from metadata)

Так как же мне нужно доверять сертификату ВПЛ? Разве этого недостаточно, когда он проверяется с помощью открытого ключа, указанного в метаданных? Нужно ли мне импортировать что-то из IdP в мою папку cert?

Комментарии:

1. Звучит как недоразумение. Доверие обычно настраивается путем импорта метаданных. Maby вам необходимо добавить сертификат для центра сертификации, выдавшего сертификат IdP, который еще не используется вашей системой

2. Как бы я сообщил своей системе, что сертификат является надежным? Я думал, что этого достаточно, чтобы импортировать метаданные IPL, которые содержат сертификат.

3. Зависит от того, какой IdP вы используете. Вы говорите, что ВПЛ сказал вам, что ИП не доверяет их сертификату. Вы получили сообщение об ошибке, которое отправили им? Или откуда они это узнали?

Ответ №1:

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

В стандартном веб-потоке, инициированном SP, приведено объяснение того, где и как используются сертификаты:

  • SP --> IdP Запрос AuthnRequest, отправленный SP, подписывается с помощью закрытого ключа SP, IdP проверяет подпись AuthnRequest с помощью открытого ключа SP
  • IdP --> SP По крайней мере, часть ответа SAML, отправленного ВПЛ, будет подписана. Если всего ответа нет, то должно быть утверждение внутри. Если весь ответ подписан, то утверждение не обязательно должно быть подписано. В любом случае подпись будет выполнена с помощью закрытого ключа IdP, и SP подтвердит ее с помощью открытого ключа IdP.

Некоторые продукты (и, вероятно, все системы/библиотеки DIY) могут позволить вам подписать как ответ, так и утверждение, но для этого нет причин — никаких. Это не дает никаких дополнительных преимуществ сверх одного только подписания ответа.

Как отмечает Стефан в своих комментариях по этому вопросу, эта «проблема», как правило, решается в продуктах с помощью передачи метаданных для самостоятельной настройки, а не просто обмена по электронной почте некоторыми URL-адресами и открытыми ключами. Типичным потоком обмена метаданными является то, что SP предоставляет IdP базовый файл метаданных, который определяет URL-адрес ACS SPS, открытый ключ SP для проверки подписи и атрибуты, необходимые для их применения. Затем IdP загружает это, выясняет, какие у них есть атрибуты, соответствующие требованиям к атрибутам SP, а затем генерирует их метаданные, содержащие URL-адреса их протоколов (например, куда следует отправлять запросы на аутентификацию), сертификаты и тому подобное, отправляя их обратно в SP. SP загружает его, и ты отправляешься на скачки.

Метки: