Вопрос 1 : есть ли возможность проверить логин + пароль в Perl через SAML у провайдера идентификации (IdP)?Если да: как?
Ответ :
Определенно Нет с точки зрения кибербезопасности.
Вопрос 2 : Я знаю, что это не обычный способ работы SAML.
Ответ :
Да.Вы правы.
(I) Спецификация SAML определяет три роли: пользователь, поставщик удостоверений (IdP) и поставщик услуг (SP).В основном случае использования SAML пользователь запрашивает доступ к услуге или вход в веб-приложение от поставщика услуг.Поставщик услуг запрашивает и получает подтверждение аутентификации от поставщика удостоверений.На основе этого утверждения поставщик услуг может принять решение об управлении доступом для пользователя, то есть он может решить, разрешить ли пользователю доступ к услуге или войти в веб-приложение.
(II) Перед доставкой предметного подтверждения в SP IdP может запросить некоторую информацию у пользователя (например, имя пользователя и пароль) для аутентификации пользователя.SAML определяет содержимое подтверждения, которое передается из IdP в SP.
(II.a) В SAML один поставщик удостоверений может предоставлять подтверждения SAML для многих SP.
(II.b) Точно так же один SP может полагаться на утверждения и доверять многим IdP.Это будет сценарий SAML вашего веб-приложения, если ваш менеджер по продукту решил запросить у всех 4 разных клиентов вашего веб-приложения собственный IdP SAML.Например, некоторые социальные сайты позволяют своим пользователям входить в свою учетную запись через аутентификацию личности, предоставляемую сторонними IdP, такими как Google, Facebook, LinkedIn через протокол OAuth 2 или протокол OpenID Connect / OAuth 2 (вместо SAML).
Вопрос 3 : Основой для этого является то, что у нас есть 4 разных клиента для нашего веб-приложения, которое должно включать центральный пароль через SAML, которые реализованы в совершенно разных технологиях.
Ответ :
Если 4 разных клиента для вашего веб-приложения должны активировать центральный пароль через SAML, они могут реализовать свой собственный SAML IdP в совершенно разных технологиях или на языке программирования, напримеркак Java, PHP или Scala.
(I) Например, мы разработали нашу прежнюю версию Система аутентификации и авторизации с нулевым паролем в Java и использовали Javaоснованный на Shibboleth IdP для обеспечения единого входа SAML для корпоративных приложений.
Мы разработали нашу текущую версию Системы аутентификации и авторизации по нулевому паролю с масштабируемостью и высокой доступностью в Scala обеспечить единый вход SAML для корпоративных приложений без Shibboleth IdP.
(II) Независимо от того, какую технологию или язык программирования используют 4 разных клиента вашего веб-приложения для реализации своего собственного IdP SAML, их IdP SAML требуется только для аутентификации своих пользователей с использованием центрального хранилища / хранилища данных паролей (например, OpenLDAP или MySQL) локально, а затем доставьте информацию о пользователе с помощью подтверждения SAML / ответа SAML вашему веб-приложению / поставщику услуг SAML.Вашему веб-приложению / поставщику услуг SAML просто необходимо сопоставить информацию о пользователе, содержащуюся в утверждении SAML, с информацией о локальном пользователе вашего веб-приложения.
Вопрос 4 : Наш менеджер по продукту решил, чтоSAML-соединение слишком сложное для 4-х клиентов, и поэтому аутентификация должна осуществляться централизованно в веб-приложении.
Ответ :
Если аутентификация по идентификатору пользователя должна выполняться централизованно вВ вашем веб-приложении вместо SAML IdP 4 различных клиента НЕ нуждаются в реализации своего собственного SAML IdP с точки зрения кибербезопасности.
Вместо этого вам просто нужно создать и назначить разные субдомены для всех 4 разных клиентов, то есть все 4 разных клиента вашего веб-приложения имеют доступ к различным субдоменам, таким как client-org1.your-web-app.com, client -org2.your-web-app.com, client-org3.your-web-app.com, client-org4.your-web-app.com.
Обратите внимание, что на другом поддомене веб-приложения отображается одна и та же страница входа Пример № 1: client-org1.box.com, client-org2.box.com, если ваши клиенты также подписывают учетную запись Box, или Пример № 2: client-org1.my.salesforce.com, client-org2.my.salesforce. com, если ваши клиенты также подписываются на учетную запись Salesforce.
Вопрос 5 : клиенты передают логин и пароль в веб-приложение, как без единого входа, и веб-приложение должно централизованно проверять данные доступа.
Ответ
Разные субдомены вашего веб-приложения отображают одну и ту же страницу входа в систему.
4 разных клиента вашего веб-приложения получают доступ к разным поддоменам вашего веб-приложения, пользователи 4 разных клиентов отправляют свои логин и пароль в ваше веб-приложение (через разные URL-адреса поддомена), как без единого входа, и хранилище данных / Предполагается, что репозиторий вашего веб-приложения будет централизованно проверять данные доступа (например, логин / пароль). Тогда 4 различным клиентам вашего веб-приложения НЕ нужны IdP SAML.