Пешеходный SSO

Ответ 1

Это невозможно. Куки файлы уникальны для каждого домена, и один домен не может читать файлы cookie других доменов.

Ответ 2

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

Когда пользователь аутентифицируется на сайте-a.com, вы устанавливаете файл cookie на сайте site-a.com. Затем на сайте-b.com вы связываете динамический javascript с сайта-a.com, сгенерированный на стороне сервера script (php и т.д.), У которого есть доступ к созданному файлу cookie, а затем копировать тот же файл cookie на сайте-b.com на стороне клиента, используя js. Теперь оба сайта имеют одинаковый файл cookie, не требуя повторного входа в систему.

Вы можете шифровать/кодировать значение cookie с помощью метода, который как site-a, так и site-b знает, как декодировать, чтобы сайт-b смог проверить свою копию файла cookie. Используйте общий общий секрет, который без него будет невозможно кодировать или декодировать.

Вы видите, что на первой странице сайта site-b.com cookie нет, поэтому, если вы видите это, вы можете захотеть перезагрузить страницу после установки файла cookie.

Ответ 3

Я сделал что-то подобное. Существует приложение PHP, в котором пользователь входит в систему, система связывается с веб-службой, а затем служба проверяет учетные данные пользователя в Active Directory. Когда пользователь аутентифицируется, его сеанс PHP хранится в БД. Другое веб-приложение может читать сеанс PHP из файлов cookie и uery веб-службы в PHP-приложении, приложение PHP проверяет сеанс в базе данных и возвращает идентификатор пользователя. Таким образом, у меня есть SSO с использованием SOA.

Не полагайтесь на идентификатор пользователя, хранящийся в браузере, это ошибка безопасности, по крайней мере, шифруйте идентификатор.

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

И используйте HTTPS для обмена информацией.

Файлы cookie могут быть прочитаны, только если они принадлежат к одному домену, например:

intranet.example.com crm.example.com example.com/erp

Ответ 4

Я думаю, что ответ приходит немного позже, но, возможно, я могу помочь кому-то.

У вас может быть файл cookie/localStorage в промежуточном домене, подключенном к домашней странице, с помощью iframe

1) Вход Форма входа в любой из ваших доменов откладывает идентификационный токен в cookie на sso.domain.com событием (postMessage) 2) Проверка domain1 и domain2 включают iframe, указывающий на sso.domain.com, который читает токен и уведомляет домашнюю страницу

Чтобы упростить разработку, мы недавно выпустили перекрестный домен SSO с JWT в https://github.com/Aralink/ssojwt

Ответ 5

Вы можете получать файлы cookie через субдомены, но я не думаю, что использование файлов cookie браузера - отличное решение. Вам действительно не нужен "SSO-сервер" для реализации единого входа. Довольно легко придумать полезную нагрузку, которую распознают оба приложения. Я видел пользовательские решения SSO, которые передают полезную нагрузку с использованием XML через HTTPS.

Ответ 6

Вот решение (которое, мы надеемся, будет тщательно изучено гуру безопасности здесь):

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

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

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