Как происходит связь между поставщиком услуг и фактическим приложением в SAML?

Question

Я понимаю, что связь между IDP и SP хорошо определена в стандарте. Мне интересно, каковы способы сделать обычную связь между автономным SP и фактическим приложением.

Я предполагаю, что существуют стандартные способы, не изобретая колесо самостоятельно. Но даже spring-saml security говорит только о «пользовательском механизме», который не говорит, что это такое.

Может ли кто-нибудь указать мне правильное направление? Я искал, но я удивлен, что он не написан нигде в блогах, учебниках и т. Д. Даже в документации Shibboleth/Gluu эта часть как-то осталась одна.

Любая помощь будет оценена по достоинству.

Answer 1

Проблема в основном сводится к «Как два приложения, развернутые в надежной сети, надежно связывают друг с другом, чтобы обмениваться информацией о безопасности пользователя». Это та самая проблема, которую SAML решает для приложений, обменивающихся по ненадежной сети, и упрощается благодаря тому, что и точка аутентификации (SP), и приложение находятся под контролем одного и того же объекта = это, например. проще использовать симметричную криптографию. SP может в принципе взаимодействовать с приложением, используя либо внешний интерфейс (= через веб-браузер), либо внутренний канал (= непосредственно между собой по сети).

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

Оба SP и приложения совместно используют один и тот же домен (= веб-браузер пользователя обращается к ним на URL, который разделяет печенье)

• вы можете настроить ваш SP хранить печенье - часть информации, включая, например, UID и истечение срока действия аутентифицированного пользователя, cookie может быть зашифрован с использованием общего секрета, известного как SP, так и приложению. Это подход, используемый, например, OpenAM или Wildfly с общим файловым файлом с общим доменным зашифрованным файлом.
• альтернативой этого подхода является отправка информации об аутентифицированном пользователе из SP в приложение, например. как зашифрованный параметр HTTP POST - аналогичный подход, который делает SAML, гораздо более базовым.
• Такой же подход можно улучшить, используя другое безопасное разделяемое хранилище - например, базы данных и отправки только ссылку на запись (например, уникальный секретный идентификатор сеанса)

SP можно использовать в качестве HTTP-прокси для приложения

• в этом случае вы можете пройти аутентификацию как HTTP-заголовок для приложения, вы должны убедиться, что доступ через SP является единственным способом доступа к приложению. Это практично только тогда, когда SP является частью, например, балансировщик нагрузки (например, плагин Apache/Nginx).

SP и приложение может использовать стандартный механизм аутентификации для связи данных аутентификации

• можно использовать, например,Kerberos (который в любом случае основан на шифровании с общим ключом) или OAuth

Каждый из вариантов может иметь разные атаки и возможные уязвимости.

Мое мнение заключается в том, что добавление функциональности SAML непосредственно в приложение с использованием прокси-сервера HTTP с поддержкой SAML или стандартный продукт, который обрабатывает аутентификацию последней мили между SP и приложением (например, OpenAM), является лучшим способом. Внедрение настраиваемого механизма безопасности может показаться легким, но есть много возможностей для совершения ошибки, которая оставляет все решение уязвимым.