Вопрос 1 :
Я создаю SaaS, и моя идея состоит в том, чтобы позволить моим клиентам использовать собственную систему аутентификации для входа в мое приложение.
Каков наилучший подход для этого? У меня будет несколько клиентов, и каждый из них сможет настроить единый вход SAML.
Ответ :
(1) Каждому клиенту назначается уникальный поддомен, например,
customer1.your-software.com
customer2.your-software.com
customer3.your-software.com
(2) Субдомен каждого клиента соответствует SP SAML с соответствующими метаданными SAML SP. Конечная точка entityID и AssertionConsumerService SAML SP для каждого клиента должна быть разной.
Например, предположим, что используется SAML SP Shibboleth, entityID каждого клиента может быть
https://customer1.your-software.com/Shibboleth.sso/Metadata
https://customer2.your-software.com/Shibboleth.sso/Metadata
https://customer3.your-software.com/Shibboleth.sso/Metadata
Конечная точка AssertionConsumerServiceКаждый клиент может быть
https://customer1.your-software.com/Shibboleth.sso/SAML2/POST
https://customer2.your-software.com/Shibboleth.sso/SAML2/POST
https://customer3.your-software.com/Shibboleth.sso/SAML2/POST
(3) Каждый клиент может загрузить свои уникальные метаданные SAML SP в свою собственную систему аутентификации (например, SAML IdP (Identity Provider)).
Cloud-В корпоративном приложении SAML SP Salesforce реализовано аналогичное решение, описанное выше.
Аналогичным образом мы реализовали параллельное решение для нашего облачного IdP SAML, являющегося частью Zero-Система аутентификации и авторизации паролей .
Вопрос 2 :
Я также обеспокоен тем, как изначально загружать пользователей. Обычно компании предоставляют список электронных писем пользователей, и я просто массово вставляю их в базу данных, или у учетной записи не будет пользователей, пока они не начнут вход?
Ответ :
Поскольку SAML SP и SAML IdP (т. Е. Собственная система аутентификации вашего клиента) установили взаимное доверие посредством обмена метаданными, SAML SP (оборудованный вашимпрограммное обеспечение предприятия) должно доверять всей пользовательской информации, интегрированной из SAML IdP (т. е. собственной системе аутентификации вашего клиента).
(1) У учетной записи не будет пользователей до тех пор, пока они не начнут входить в систему.
(2) Когда новый пользователь сначала входит в облачное корпоративное приложение после сбоянайти информацию о пользователе из базы данных, ваше корпоративное веб-приложение вставит информацию о новом пользователе в базу данных.
Вопрос 3 :
Как управлять scneario, когда пользователь больше не является частью компании? компании предоставляют список пользователей для деактивации?
Ответ :
(1) Если пользователь больше не является частью компании, ваш клиент деактивирует пользователя изих система аутентификации. Тогда пользователь НЕ сможет войти в ваше облачное корпоративное веб-приложение
(I) Когда пользователь обращается к вашему облачному корпоративному веб-приложению, пользователь перенаправляется в собственную систему аутентификации вашего клиента (т.е. , SAML IdP).
(II) Деактивированный пользователь НЕ будет аутентифицирован собственной системой аутентификации вашего клиента.
(III) Деактивированный пользователь НЕ будет перенаправлен обратно в ваше облачное корпоративное веб-приложение с подтверждением / ответом SAML, в котором содержится информация о пользователе. Таким образом, деактивированный пользователь не сможет войти в ваше облачное корпоративное веб-приложение.
(2) Ваше корпоративное веб-приложение назначает административную привилегию главе ИТ каждого клиента для их собственного дочернего домена организации, такого как customer1.your-software.com.
После входа в ваше корпоративное веб-приложение ИТ-директор может удалить / удалить / деактивировать любого пользователя своей организации, например customer1, из базы данных вашего корпоративного веб-приложения.
Официальный веб-сайт Okta Что такое SCIM? предоставляет следующее описание SCIM (Система для управления междоменной идентификацией).
When changes to identities are made in the IdP, including create, update, and delete, they are automatically synced to the SP according to the SCIM protocol.
Последующие действияВопрос № 1 :
, когда пользователь проходит проверку подлинности с помощью SAML и перенаправляется на URL-адрес обратного вызова (мое приложение), что будет идеальным потоком там?
Ответ :
(1) После аутентификации пользователя с помощью SAML IdP пользователь перенаправляется на URL-адрес AssertionConsumerService вашего корпоративного приложения, который привязан к поддомену каждого клиента корпоративного приложения.
(2) Как создать и запустить Shibboleth SAML IdP и SP с использованием контейнера Docker в репозитории GitHub, содержится инструкция по созданию провайдера аутентификации / авторизации на основе SAML с использованием Shibboleth SAML IdP и OpenLDAP, а также веб-приложение SAML SP (которое можно рассматривать какупрощенное корпоративное приложение, позволяющее платным пользователям получать доступ к защищенным веб-ресурсам.)
- Shibboleth SAML IdP отвечает за федерацию идентификации.
- OpenLDAP отвечает за аутентификацию личности.
Вы можете использовать вышеуказанный репозиторий GitHub для моделирования корпоративного приложения SAML SP с несколькими клиентами и соответствующими им IdP SAML.
(I) Запустить три (3) контейнера док-станции демонстрационных приложений SAML SP (которые соответствуют трем (3) корпоративным приложениям SAML SP, подписанным тремя (3) клиентами) на одном физическом компьютере / сервере (таком как сервер Ubuntu).
(IA) Каждое демонстрационное приложение SAML SP работает на разных «внешних» портах контейнера Docker.
docker run -it --rm -p 2081:80 -p 2441:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2082:80 -p 2442:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2083:80 -p 2443:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
(IB) Используйте HAProxy для сопоставления разных «внешних» портов контейнера Docker с разнымисубдомен ваших клиентов, такой как
2441 to https://customer1.your-software.com/
2442 to https://customer2.your-software.com/
2443 to https://customer3.your-software.com/
(II). Выполнить три (3) док-контейнера SAML IdP (которые обеспечивают аутентификацию SAML для трех (3) корпоративных приложений, подписанных тремя (3) клиентами), на другомодна и та же физическая машина / сервер (например, сервер Ubuntu).
В демонстрационных целях вы можете использовать два (2) физическихмашины для SAML IdP и SAML SP с локальной DNS и конфигурацией портов для разных доменных имен, например,
10.10.40.10 customer1.your-software.com customer2.your-software.com customer3.your-software.com
10.10.40.11 customer1.saml-idp.com customer2.saml-idp.com customer3.saml-idp.com
(II.A) Каждый SAML IdP работает на разных «внешних» портах контейнера Docker.
docker run --rm -it ... -v $(pwd)/ext-conf:/opt/shibboleth-idp-ext-conf --link openldap:openldap -p 8441:8443 --name="shibboleth-idp-1" example/shibboleth-idp:latest $@
docker run --rm -it ... -p 8442:8443 --name="shibboleth-idp-2" example/shibboleth-idp:latest $@
docker run --rm -it ... -p 8443:8443 --name="shibboleth-idp-3" example/shibboleth-idp:latest $@
... means the missing docker parameters to be added (with reference to run.sh)
(II.B) Используйте HAProxy для сопоставления разных «внешних» портов контейнера Docker с другим поддоменом SAML IdP, соответствующим приложению SAML SP ваших клиентов, например
8441 to https://customer1.saml-idp.com/
8442 to https://customer2.saml-idp.com/
8443 to https://customer3.saml-idp.com/
(III) Обмен метаданными SAML между SAML SP (например, https://customer1.your -software.com / ) и SAML IdP (например, https://customer1.saml -idp.com / ).
Примечания
Вы можете посетить веб-сайт Salesforce SSO и Box SSO , чтобы узнать, как Salesforce и Box назначают разныесубдомены для разных клиентов, что позволяет клиентам настраивать свои субдомены в качестве разных SAML SP для собственных IdP SAML клиентов.
Обратите внимание, что наша система аутентификации и авторизации с нулевым паролем является технологиейпартнер Box.
Последующий вопрос № 2 :
я должен создать jwt в своем приложении с этой информацией, и если этот jwt истекает, я должен снова перенаправить на SAML?
Ответ :
Нет. Вам НЕ нужно создавать jwt в вашем корпоративном приложении.
Вместо этого, когда истекает время сеанса SSO, ваше корпоративное приложение должно быть перенаправлено в SAML IdP для другой аутентификации.
Follow-up Вопрос № 3 :
есть ли "бесплатный" idp, который я могу использовать для проверки реализации, вам известно о чем-либо?
Ответ :
Shibboleth SAML IdP - это «бесплатный» idp, который я могу использовать для тестирования реализации.
Существует два (2) варианта использования Shibboleth SAML IdP для проверки реализации вашего корпоративного приложения SAML SP.
(1) Запуск автономного Shibboleth SAML IdP
Как собрать и запустить Shibboleth SAML IdP и SP с помощью контейнера Docker в репозитории GitHub позволяет создавать и запускать автономныйIdP Simulator на вашем собственном стенде. Запуск автономного SAML IdP Simulator позволяет вам протестировать код SP и отладить журнал SAML SP, проверив журналы сервера как IdP, так и разработанного вами SP.
(2) Использование онлайн-Shibboleth SAML IdP
TestShib - это онлайн-симулятор Shibboleth IdP, созданный и управляемый сообществом Shibboleth. Веб-сайт TestShib демонстрирует
"Один из создателей сервиса TestShib создал альтернативу TestShib для всеобщего блага. Сайт называется SAMLTest (предлагается Signet) *, и выможете узнать о них больше, перейдя в эти места. "