В общем, что-то вроде этого. Существует шифрование, а затем пение в SAML. Вы никогда не хотите быть в производстве без использования цифровой подписи для SAML. Вы можете отключить обработку подписи для тестирования. Мы разрешаем это в SiteMinder Federation Servcies (SMFSS) только для целей тестирования. Итак, сказав, что вы ничего не говорите о цифровых подписях, а говорите только о шифровании.
Но вот краткое изложение двух в моем собственном очень тупом описании, которое, хотя я и звучу глупо из-за того, как я это объясняю, я надеюсь, что это поможет вам. И если вы уже знаете это, я прошу прощения заранее. Еще одна вещь заключается в том, что это очень просто, но вы можете получить более подробную информацию о поиске в Google для шифрования, дешифрования, сертификатов и т. Д.
Собственно, вот краткое изложение того, что я использую для обучения новых сотрудников службы поддержки федерации с помощью SMFSS (SiteMinder Federation Services), и в конце приведен раздел, который я написал о сертификатах. Это было просто кое-что, что я написал очень быстро и не очень хорошо выглядело, но оно определенно выполняет свою работу и быстро. Это было написано как копия того, что я делаю с клиентами POST SAML 2.0 POST, у которых уже есть настройка SiteMinder. Я просто подумал, что дам вам это, так как в нем есть много инструментов, которые вы можете найти полезными, когда начнете работать, если вы еще не знали о них. ; -)
Вам потребуются две среды с агентом, агентом OP, сервером политики, сервером политики. Нужно два агента, чтобы один мог быть IDP и один SP.
Чтобы настроить Agent Option Pack, см .:
Глава 8. Настройка приложения веб-служб федерации и развертывание веб-служб федерации в качестве веб-приложения и настройка ServletExec для работы с веб-службами федерации
Теперь настройте аутентификацию SAML 2.0 POST: вы должны использовать следующее, шаг за шагом. Но сначала посмотрите главу о настройках, которые должны совпадать, поскольку они должны совпадать для сторон IDP и SP. Приведенные ниже главы по настройке IDP и SP в значительной степени шаг за шагом, действительно, следуйте шагам 14 и 16 шаг за шагом, и все готово.
Глава 22: Параметры конфигурации, которые должны использовать одинаковые значения
Затем используйте это для настройки IDP и SP:
Глава 14. Настройка SiteMinder в качестве поставщика удостоверений SAML 2.0
Глава 16. Настройка SiteMinder в качестве поставщика услуг SAML 2.0
Запустите транзакцию SAML 2.0 и получите ее Fiddler Trace. Вытащите сертификаты и создайте файл .cer. Вытащите утверждение и проверьте XML в Интернете, используя инструменты ниже.
Настройте Fiddler Tool и убедитесь, что у вас включена дешифровка HTTPS. У меня была ссылка здесь, но просто зайдите в gllgle и введите «Fiddler Tool HTTPS decryption», и вы получите ее.
Используется для просмотра размещенного или перенаправленного URL-адреса с транзакциями SAML, снятыми с Fiddler. Обычно:
https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php
Я использовал это несколько раз для проверки XML (утверждения), когда я получаю ошибки синтаксического анализа или другие ошибки, когда партнеры говорят, что наше утверждение не является хорошим, или если у нас есть утверждение партнера, которое не является хорошим. Я хотел бы сначала проверить синтаксис, и если это нормально, то проверить спецификации SAML, чтобы увидеть, имеют ли они правильные значения в самом утверждении SAML. Другими словами, убедитесь, что он соответствует SAML.
http://www.w3schools.com/dom/dom_validate.asp
СОВЕТ: Вы можете взять информацию о сертификате в кодировке Base 64 из наших журналов или из Fiddler Traces, вставить их в блокнот и сохранить как name.cer. Затем, когда вы открываете этот файл, вы можете посмотреть, какой сертификат использует клиент. Это полезно, потому что тогда вы можете увидеть, есть ли у них правильный сертификат, и узнать, кто является их корневым CA или промежуточным корневым CA. Убедитесь, что вы получаете все данные, включая = или ==, которые могут находиться в конце строк для информации сертификата.
При выполнении SLO или Artifact партнер должен будет подключиться по обратному каналу к веб-серверу на сайте других партнеров.Когда это происходит, подключаемый веб-сервер обслуживается по протоколу SSL / HTTPS.Это означает, что тот, кто подключается к этому серверу, должен иметь сертификат ROOT CA, который подписал сертификат веб-сервера в своем хранилище ключей.Теория этого та же, что и при открытии браузера и подключении к веб-серверу HTTPS.Все браузеры поставляются с уже импортированными основными сертификатами Root CA.Весь смысл в том, что когда вы размещаете сертификат на веб-сервере, он не защищает, а просто сообщает всем, кто подключается, что вы действительно являетесь тем веб-сайтом и действительно являетесь тем, кем вы себя называете.Тот факт, что у вас есть сертификат, делает ваш сайт HTTPS, и причина, по которой вы считаете, что они являются теми, кем они себя называют, заключается в том, что они дают вам свой сертификат при подключении, и если у вас есть ROOT CA для этого сертификата на веб-сайте, это означаетВы доверяете своим корням CA.если вы доверяете их ROOT CA, то вы можете подключиться.Если у вас нет сертификата ROOT CA, импортированного в ваш браузер, вы не сможете подключиться через SSL / HTTPS к этому веб-серверу.
** Шифрование и дешифрование (если пакет считывается с провода, данные шифруются для безопасности пакетных данных):
Шифрование выполняется на стороне IDP, и вы можете зашифроватьполное утверждение, значение NameID, атрибуты и, возможно, больше?
Шифрование выполняется на стороне IDP с использованием сертификата ключа PUBLIC (сертификата SP), который предоставляется IDP в автономном режиме SP.
Когда SP получает утверждение (или что-то еще, зашифрованное IDP), он должен иметь свой закрытый ключ в своем хранилище ключей, чтобы он мог расшифровать данные и прочитать их.Это расшифровка.
Причина, по которой это безопасно и защищает данные, заключается в том, что ТОЛЬКО у SP должен быть свой собственный ключ PRIVATE.Таким образом, если этот пакет был украден, никто не сможет расшифровать его, кроме них.
*** Подписание и проверка - это не БЕЗОПАСНО, поскольку не шифрует данные.Оно не предназначено для обеспечения безопасности пакетов, оно предназначено для того, чтобы сообщить кому-то, кто вы на самом деле, кем вы себя называете.Так что, если вы подпишете и подтвердите, ваш партнер будет знать, что он поступил от ВПЛ, от которого он ожидал.
IDP должен использовать свой открытый / закрытый ключ PAIR для подписи данных.
SP должен использовать PUBLIC-ключ IDP (предоставленный SP в автономном режиме) для проверки подписи.Причина, по которой вы знаете, что данные получены от этого IDP, заключается в том, что ТОЛЬКО данные подписаны закрытым ключом IDP и расшифрованы их открытым ключом.Другими словами, вы не можете притворяться, что вы этот IDP, и отправлять подписанные данные в SP и заставлять их думать, что это IDP, потому что открытый ключ для IDP можно использовать только для проверки того, что подписано с помощью соответствующего закрытого ключа.Это доказывает, что вы тот, кем вы говорите.
конец глупого технота, который я написал **
Надеюсь, вы найдете информацию о сертификатах и инструменты, полезные в ваших будущих начинаниях SAML!Счастливого объединения!
обновление - я не смог опубликовать все ссылки, но некоторые из них были только расшифровкой base 64, так как это позволит мне опубликовать только две, которые я отправляю самые нужные две.
Спасибо!Crissy Stone CA Technologies Поддержка SiteMinder