Удобные приложения для профилей Browser / POST и Browser / Artifact SAML

Question

Я предлагаю использовать SAML 1.1 в качестве технологии для проверки Web SSO в среде клиентов, и они спросили меня кое-что интересное:

Какой сценарий Браузер / профиль POST подходит и какие сценарии Браузер / Профиль артефакта SAML подходит?

Фактически, Характеристики SAML 1.1 не говорят ни о лучшем, ни о наиболее подходящем сценарии для обоих профилей браузера.

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

* Примечание. В решении используется Weblogic Server 10.0 и поддержка SAML 1.1.

Answer 1

Мне показалось, что оба профиля предлагают одинаковые уровни безопасности. С профилем POST пользователь должен явно инициировать POST. Это может помочь что-то помешать атаке CSRF, но я не знаю никаких реальных подвигов. Профиль Artifact, с использованием метода GET, может обеспечить более плавное взаимодействие с пользователем.

Для меня недостатком профиля Артефакта является сложность открытия заднего канала. Мой сервер приложений выделяет поток для обработки пользовательского запроса, и если этот поток блокируется (ожидает завершения ввода-вывода обратного канала) очень долго, сервер приложений начинает работать очень плохо. Таким образом, связь по обратному каналу должна выполняться очень осторожно, чтобы гарантировать, что она истекает через определенный промежуток времени.

Даже тогда, если IdP не работает, у моих пользователей не так очевидно, что ошибка в IdP. С профилем POST, если IdP ведет себя плохо, пользователи с меньшей вероятностью будут винить меня.

Answer 2

С точки зрения безопасности, основное отличие состоит в том, что с профилем POST ответ SAML (содержащий утверждение) проходит через браузер конечного пользователя, поэтому он ДОЛЖЕН быть подписан и, возможно, зашифрован, если вы не хотел бы, чтобы конечный пользователь мог видеть.

С профилем артефакта вы можете использовать SSL для защиты обратного канала и отправки неподписанного, незашифрованного утверждения, поскольку оно передается непосредственно от IdP к SP. Вы все еще можете подписать утверждение об отказе от ответа, однако.

Однако, как упоминает Эриксон, настройка исходящего «обратного канала» соединения от SP к IdP сопряжена со своими собственными проблемами. По этой причине большинство развертываний SAML используют POST.

Кстати, - по какой причине вы используете SAML 1.1, а не 2.0?