Удобные приложения для браузера/POST и Browser/Артефакт SAML профилей

Question

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

Какой сценарий браузера/POST является подходящим, и какими сценариями является профиль браузера/артефакта SAML?

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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