Единый вход для нескольких доменов [закрыто]

110

В нашей компании настроено несколько доменов, на каждом из которых размещен один веб-сайт. В настоящее время каждый домен имеет собственную аутентификацию, которая выполняется с помощью файлов cookie.

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

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

Спасибо.

Изменить: веб-сайты представляют собой смесь сайтов в Интернете (внешний) и интранет (используются внутри компании).

authentication single-sign-on паскаль
источник
Это похоже на работу для OpenID, но разрешить только идентификаторы из вашего домена входа.
Нилл, 04
2
@Will Этот вопрос может быть не для этого веб-сайта в сети SE, но определенно конструктивный .
Binar Web
@BinarWeb Причины закрытия изменились с 2008 года. Тогда это был наиболее подходящий вариант.

Ответы:

91

Реализованное здесь решение SSO работает следующим образом:

  1. Существует главный домен login.mydomain.com со скриптом master_login.php, который управляет логинами.
  2. В каждом клиентском домене есть скрипт client_login.php
  3. Все домены имеют общую базу данных сеансов пользователей.
  4. Когда клиентский домен требует, чтобы пользователь вошел в систему, он перенаправляет на главный домен (login.mydomain.com/master_login.php). Если пользователь не вошел в систему на главном сервере, он запрашивает аутентификацию у пользователя (т. Е. Отображает страницу входа в систему). После аутентификации пользователя он создает сеанс в базе данных. Если пользователь уже аутентифицирован, он ищет идентификатор сеанса в базе данных.
  5. Главный домен возвращается в клиентский домен (client.mydomain.com/client_login.php), передавая идентификатор сеанса.
  6. Клиентский домен создает файл cookie, в котором хранится идентификатор сеанса от мастера. Клиент может узнать зарегистрированного пользователя, запросив общую базу данных с использованием идентификатора сеанса.

Ноты:

  • Идентификатор сеанса - это уникальный глобальный идентификатор, созданный с помощью алгоритма из RFC 4122.
  • Master_login.php будет перенаправлять только на домены из своего белого списка
  • Мастер и клиенты могут находиться в разных доменах верхнего уровня. Например. client1.abc.com, client2.xyz.com, login.mydomain.com
Grom
источник
Это похоже на хорошее решение люверса. Что вы храните в базе данных? Это (session_id, username, hashed_password)?
Jon M
3
Как вы поступаете в случае отказа главного домена login.mydomain.com? В этот момент невозможно войти в систему?
jjxtra 08
3
Кто-нибудь произвел какие-либо примеры кода или репозиторий на github?
Джошуа Ф. Рунтри
Это то, что задают почти все протоколы SSO (например, SAML), но с большей защитой от атак повторного воспроизведения и т.д.
cweiske
2
Что, если они не используют общую базу данных пользователей? Каждое партнерское веб-приложение имеет собственную базу пользователей. Как мы с этим сталкиваемся?
застрял overflow
33

Не изобретайте колесо заново. Существует ряд пакетов междоменного единого входа с открытым исходным кодом, таких как JOSSO, OpenSSO, CAS, Shibboleth и другие. Если вы используете технологию Microsoft повсюду (IIS, AD), вы можете вместо этого использовать федерацию Microsoft (ADFS).

Markc
источник
4
Абсолютно верно - я видел слишком много людей, использующих собственные решения безопасности, только для того, чтобы обнаружить, что они уязвимы для повторного воспроизведения, XSRF или других атак
5
+1 Вы [почти] никогда не должны изобретать колесо безопасности заново.
Марк Э. Хаасе
13
OpenSSO мертв, а JOSSO и CAS - это решения JAVA. Просто к вашему сведению
OneHoopyFrood
15

Насколько разные имена хостов?

Эти хосты могут использовать файлы cookie:

  • mail.xyz.com
  • www.xyz.com
  • logon.xyz.com

Но они не могут:

  • abc.com
  • xyz.com
  • www.tre.com

В первом случае вы можете использовать решение на основе файлов cookie. Подумайте GUID и таблицу сеанса базы данных.

Джейсон Сальдо
источник
2

Если вы используете Active Directory, каждое приложение может использовать AD для аутентификации, тогда вход в систему может быть беспрепятственным.

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

Майк
источник
2
Разве пользователю все еще не нужно вводить имя пользователя и пароль на domain1.com, domain2.com и domain3.com, когда он впервые заходит на эти сайты в течение этого сеанса?
HaBo