Пешеходный SSO

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

В моем сознании это работает так:

  • пользователь регистрируется в приложении
  • приложение проверяет учетные данные, а затем настраивает cookie на браузер, сохраняющий имя пользователя (которое может быть закодировано с помощью закрытого ключа)
  • если пользователь открывает другое приложение, он ищет файл cookie и читает имя пользователя в значении (с использованием ключа для декодирования строки)

В этом решении пользователь может видеть cookie браузера (другого пользователя) и возьмите строку, кодифицированную из имени пользователя. Затем он мог добавить его на собственный файл cookie (ничего хорошего!).

Есть ли безопасный способ сделать это? При управлении на основе временной метки или что-то вроде этого?

Спасибо заранее.

Bye

P.S. Я знаю, что мой английский не очень хорошо.. извините за это!

ОТВЕТЫ

Ответ 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

cross domain sso

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-адрес клиента в зашифрованный токен для дополнительной безопасности.