Блог

Мы должны интегрировать сторонний SP для единого входа. Наше приложение представляет собой оболочку spring (не springboot) и имеет модуль аутентификации / авторизации, вызывающий серверную службу с использованием mongo в качестве DB. Теперь требуется интегрировать единый вход на основе SAML SP с третьей стороной. Третья сторона предоставила документы, в которых запрашивается IDP. В предоставленном требовании от SP утверждение Nameid должно быть постоянным, уникальным и непрозрачным и может быть идентификатором пользователя клиентского приложения (нашего приложения). Я считаю, что для интеграции с SP нам нужен IDP, такой как SSOCircle или Okta, или какой-либо IDP с открытым исходным кодом. И я думаю, что мы можем написать отдельный IDP springboot SAML и предоставить api для нашего устаревшего spring для входа в SP. Поток, насколько я понимаю:

1. Пользователь с нашего портала получает доступ к стороннему веб-сайту SP или API.
2. Сторонний SP перенаправит пользователя на наш IDP для входа в систему.Они сохранят NameID (UUID сопоставление идентификаторов пользователя или идентификаторов пользователя) в конце, который они передадут как запрос SAML вместе с другими утверждениями.
3. Как только пользователь успешно войдет в систему, наш IDP перенаправит пользователя на сторонний SP с успешным ответом.

Мои вопросы :

1. Можем ли (или должны ли мы) обойти IDP? Я думаю, это означало бы, что мы пишем SAML IDP самостоятельно. Пожалуйста, дайте мне знать мои лучшие варианты или стоит ли обходиться без IDP и писать наш собственный эквивалент.Если мы не можем, я бы предположил, что мы покупаем платные проприетарные или используем IDP с открытым исходным кодом.
2. Утверждение Nameid (уникальное, постоянное, непрозрачное): это одно из требований SP.Если нам нужно использовать IDP (что я думаю), и это требование к утверждению потребителя — использовать постоянный идентификатор имени для передачи.Он должен быть уникальным, постоянным и непрозрачным. Итак, мы считаем, что сопоставление идентификаторов пользователей UUID в запросе SAML с IDP должно быть в порядке. Если мы пойдем таким образом, нам придется сохранить сопоставление UUID в БД как утверждение nameid. Должны ли мы использовать только идентификаторы пользователей нашего портала в качестве идентификаторов имен или UUID в интеграции DP -SP для удовлетворения требований? Пожалуйста, прокомментируйте, какой подход является правильным.
3. Ограничения на сохраняемость идентификаторов на стороне IDP, а также на стороне SP: на нашем конце есть одно узкое место.Наша команда ИТ-безопасности, вероятно, не разрешит UUID постоянного сопоставления NameID навсегда из соображений безопасности, в этом случае сопоставление NameID изменится с нашей стороны. Как следует решить эту проблему, если нам нужно использовать UUID в качестве nameid?
4. Инициализация NameID: когда пользователь с нашего портала запрашивает вход в SP — будет ли он передан SP в качестве запроса на вход, а затем SP создает запрос saml и передает утверждения nameids в IDP? Если да, каков наилучший подход для передачи идентификаторов имен в SP в качестве запроса на вход? Если нет, то как SP узнает, какой UUID передать в SAML IDP? Как мы будем решать эту проблему, если идентификаторы имен сопоставления являются идентификаторами UUID, которые могут измениться из-за проблем безопасности? . Другое дело, что, хотя упоминается nameid, он упоминается как «постоянный» в требовании, но в примерах документа с требованиями, которые они показывают urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . Я думаю, что это, вероятно, ошибка в документе. [?].
5. Любой пример единого входа SAML IDP (клиентского) приложения, на которое мы можем сослаться, который близок к приведенным выше 1) и 2)?

Можем ли (или должны ли мы) обойти IDP? Я думаю, это означало бы, что мы пишем SAML IDP самостоятельно.

Нет, вы не можете. Если третья сторона выступает в качестве поставщика услуг SAML, вам необходимо использовать или выступать в качестве поставщика идентификационных данных SAML. Создание собственной реализации — довольно сложная задача, и вы можете либо использовать IdP на основе SAAS, например SSO Cirle (имейте в виду, что ваш клиент должен принять, где хранятся идентификационные данные пользователя), либо развернуть свой собственный IdP SAML. Есть платные продукты / услуги или бесплатные. Открытый исходный код не обязательно означает бесплатный, это часто неправильно понимают.

Если вам все равно нужен SAML IdP, вы можете подумать о том, чтобы ваше собственное приложение также действовало как SAML SP, чтобы использовать аутентификацию IdP.

Какой формат NameID использовать — это своего рода соглашение. Спецификация SAML предлагает использование определенного формата NameID для определенных целей, например

• Формат ‘transient’ NameID предназначен для использования только для потока единого входа.
• «постоянный» предназначен для использования, когда вы хотите связать идентификаторы разных хранилищ идентификаторов вместе

SP может использовать значение значения NameID в теме, чтобы найти профиль пользователя или выполнить автоматическую федерацию (создать профиль на своей стороне). Для достижения того же самого можно также использовать атрибуты из инструкции атрибута SAML. Многие реализации SP предлагают это.