Єдина реєстрація в кількох доменах [закрито]


110

У нашої компанії є кілька доменів, створених з одним веб-сайтом, розміщеним на кожному з доменів. Наразі кожен домен має власну автентифікацію, яка здійснюється за допомогою файлів cookie.

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

Я думав рухатися до єдиного знаку (SSO), щоб цю проблему можна було усунути. Буду вдячний за будь-які ідеї, як цього можна досягти, оскільки я не маю жодного досвіду в цьому плані.

Дякую.

Редагувати: Веб-сайти поєднують веб-сайти Інтернет (зовнішній) та інтранет (внутрішній, що використовується у компанії).


Це виглядає як робота для OpenID, але дозволяти лише ідентифікатори з вашого домену входу.
Нелл

2
@Will Це питання може не бути для цього веб-сайту в мережі SE, але, безумовно, конструктивне .
Веб

@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. Клієнтський домен створює печиво, яке зберігає ідентифікатор сеансу від головного. Клієнт може дізнатися зареєстрованого користувача, запитуючи спільну базу даних за допомогою ідентифікатора сеансу.

Примітки:

  • Ідентифікатор сеансу - це унікальний глобальний ідентифікатор, згенерований за допомогою алгоритму RFC 4122
  • Master_login.php буде переспрямовувати лише до доменів у своєму списку
  • Майстер та клієнти можуть знаходитись у різних доменах верхнього рівня. Напр. client1.abc.com, client2.xyz.com, login.mydomain.com

Це виглядає як гарний розчин гром. Що ви зберігаєте в базі даних? Це (session_id, ім’я користувача, хеш-пароль)?
Джон М

3
Як вирішувати випадок, коли основний домен login.mydomain.com знижується? Чи неможливо ввійти в цей момент?
jjxtra

3
Будь-який орган видав будь-які приклади коду чи рефінансування github?
Джошуа Ф. Ріндрі

Це вказано майже у всіх протоколах SSO (наприклад, SAML), але з більшою безпекою від атак повторного повторення тощо.
cweiske

2
Що робити, якщо вони не діляться базою даних користувачів? Кожен веб-додаток-партнер має власну базу користувачів. Як ми стикаємося з цим?
застряг над потоком

33

Не заново вигадуйте колесо. Існує низка міждоменних пакетів SSO з відкритим кодом, таких як JOSSO, OpenSSO, CAS, Shibboleth та інші. Якщо ви використовуєте технологію Microsoft протягом усього часу (IIS, AD), замість цього можна використовувати федерацію мікрософт (ADFS).


4
Абсолютно - я бачив, як занадто багато людей отримують власні рішення щодо безпеки лише для того, щоб виявити, що вони вразливі до відтворення, XSRF або інших атак

5
+1 Ви повинні [майже] ніколи не винаходити колесо безпеки.
Марк Е. Хааз

13
OpenSSO мертвий, а JOSSO і CAS - рішення JAVA. Просто FYI
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 для автентифікації, вхід у систему може бути безперебійним.

В іншому випадку, якщо програми можуть спілкуватися один з одним за кадром, ви можете використовувати sessionids та мати один додаток, який обробляє ідентифікатор, що обслуговує всі ваші інші програми.


2
чи не потрібно користувачеві вводити ім’я користувача та пароль на domain1.com і domain2.com та domain3.com, коли він вперше приземляється на ці сайти для цього сеансу?
HaBo
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.