Аутентификация (настройка файлов cookie) на 2 отдельных доменах

Question

Буду признателен за любые мысли / идеи, которые могут возникнуть у любого из вас по этому поводу ...

У меня есть два домена, на которых запущены одни и те же приложения, например mysite.com и mysite.org, и у меня есть требование, чтобы, когда пользователь входит в mysite.com, он также должен был войти в mysite.org. Очевидно, я не могу установить cookie в другом домене, но я хочу найти разумное, безопасное решение. Я думаю, что у меня есть решение (на бумаге), но я просто хотел бы получить отзыв о том, как его улучшить и обезопасить.

Моя таблица сессий сейчас выглядит так:

id: auto-incrementing; only used for by ActiveRecord
uuid: Universally Unique Identifier used for session lookup
user_id: the user this session belongs to
user_ip_address: the user's IP address
created_at: self-explanatory
updated_at: self-explanatory

Моя текущая логика аутентификации на одном домене:

1. Пользователь пытается получить доступ к mysite.com/some_protected_info; они не проходят проверку подлинности, поэтому они перенаправляются на страницу входа (реферальный URL-адрес хранится в файле cookie)
2. Пользователь успешно проходит аутентификацию на mysite.com; сеанс создается в БД; создается файл cookie для mysite.com; пользователь перенаправляется на URL-адрес реферала в файле cookie, т.е. mysite.com/some_protected_info.

Моя предложенная логика для аутентификации на двух доменах:

1. Пользователь пытается получить доступ к mysite.com/some_protected_info; они не прошли проверку подлинности, поэтому они перенаправляются на страницу входа (реферальный URL-адрес хранится в файле cookie)
2. Пользователь успешно проходит аутентификацию на mysite.com; сеанс создается в БД; создается файл cookie для mysite.com; Затем пользователь перенаправляется на mysite.org, например mysite.org/login/special
3. Специальное действие контроллера входа просматривает сеанс, определяет его действительность, устанавливает cookie на mysite.org и перенаправляет обратно на другое действие контроллера на mysite.com.
4. Учитывая, что пользователь прошел аутентификацию на mysite.com (и, вероятно, mysite.org), пользователь будет перенаправлен обратно по реферальному URL (mysite.com/some_protected_info).

Примечание: - Оба сайта используют SSL. - На обоих сайтах используется один и тот же код (экземпляры mongrel) - конфигурация Apache делает его доступным через разные домены, то есть параметры config.action_controller.session на обоих доменах абсолютно одинаковы.

Вопросы:

В (2) я должен передать UUID через SSL или это проблема безопасности? Должен ли я генерировать новый, случайный, временный идентификатор для поиска сеанса?

В (3) я должен передавать реферальный URL (mysite.com/some_protected_info) или безопасно просто перенаправить обратно к значению cookie на mysite.com?

Есть какие-нибудь ошибки? Особые ситуации, которые я пропускаю?

Answer 1

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

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

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

Хотя UUID могут показаться достаточно уникальными, генератор может выдавать предсказуемые числа или числа с недостаточной случайностью.Вот почему отправка «подписывающего» значения полезна для предотвращения подделки.

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

Answer 2

Это не реальный ответ, но если вы владеете двумя доменами, вы можете установить свои куки, используя куки-файлы кросс-доменной политики:

например, вы можете создать crossdomain.xml на yourdomain.com:

<?xml version="1.0" ?>
<cross-domain-policy>
  <allow-access-from domain="yourdomain.org" />
</cross-domain-policy>