Чтобы реализовать SSO, я работал с некоторыми IdP и установкой Shibboleth SP, но не смог ответить на этот вопрос.
На стороне IdP у меня есть несколько файлов метаданных, описывающих некоторые приложения. Эти файлы могут содержать сертификат, но если ничего не указано, связь по-прежнему работает нормально. Если я помещаю те же файлы на сторону SP, он по-прежнему работает нормально, даже если в качестве сертификата помещаю некоторые случайные символы.
Может ли кто-нибудь объяснить мне, как это работает и какова цель этих сертификатов X509 в этом файле метаданных (IdP)?
Эти сертификаты являются якорями доверия. Они позволяют вам проверять подписи и, следовательно, устанавливать доверие к сообщениям, которыми обменивались. (Это очень похоже на доверенные сертификаты CA, которые настроены в вашем браузере для проверки подлинности сертификатов сайтов HTTPS.)
Запросы и ответы SAML должны быть подписаны (как минимум, ответы). Вы найдете такие элементы, как <ds:DigestMethod />, <ds:DigestValue /> и <ds:SignatureValue /> (хотя это можно упростить, если вы используете привязку перенаправления HTTP).
Когда SP получает ответ SAML от IdP через браузер, он должен убедиться, что полученная им подпись исходит от известного ему IdP и что подписано с использованием закрытого ключа IdP; эта подпись может быть проверена по общему ключу IdP в сертификате, настроенном в метаданных.
Невыполнение этого для SP делает весь процесс бесполезным, а возможность принять любое утверждение без проверки подлинности сообщения IdP предполагает ошибку конфигурации.
Со стороны IdP это в некоторой степени менее важно. Это необходимо только в том случае, если IdP желает убедиться, что запрос действительно исходит от доверенного поставщика SP. Это особенно полезно, если SP запрашивает раскрытие определенных конфиденциальных атрибутов (которые должны видеть не все SP) и, возможно, для шифрования этих атрибутов в ответе, чтобы только этот SP мог его прочитать.
При этом Shibboleth может выпускать эти атрибуты через обратный канал (службу атрибутов), где соединение между SP и IdP устанавливается напрямую (без обмена сообщениями с браузером). Аутентификация между SP и IdP все равно должна происходить в этом случае, но я думаю, что она может работать на транспортном уровне (например, аутентификация клиент-сертификат) вместо уровня сообщения (через подписи SAML), я не уверен. В любом случае для этого также потребуется настроить якоря доверия.
Эти сертификаты нужны для того, чтобы гарантировать, что данные, которыми обмениваются idp и sp:
Это функции безопасности протокола, которые нельзя упускать при развертывании производственной системы.
В системах, которые входят в состав федерации, фактически используются сертификаты x509 (они обязательны).
Сертификаты X509 содержат ключи для криптографии с открытым ключом, а ключ IdP может использоваться либо для подписи сообщений от IdP, либо для шифрования сообщений для IdP, либо для обоих (хотя обычно сообщения для IdP не шифруются).
Взгляните на этот вопрос о переполнении стека, чтобы узнать разницу между подписью и шифрованием: https://stackoverflow.com/questions/454048/what-is-the-difference-between-encrypting-and-signing-in-asymmetric-encryption
Взгляните на документацию Shibboleth, чтобы увидеть примеры использования ключей в метаданных: https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataKeyDescriptor
Будет ли ключ фактически использоваться для подписи или шифрования, зависит от профиля сообщений, передаваемых между IdP и SP. То есть, в формате SAML1 или SAML2 сообщения, и какие конечные точки используются.