Cross Domain Login - Как автоматически войти в систему пользователя при переносе из одного домена в другой

Ответ 1

Единый вход (SSO) концептуально довольно прост.

• Пользователь нажимает domain1.com.
• domain1.com не видит там cookie сеанса.
• domain1.com перенаправляется на sso.com
• sso.com представляет страницу входа и принимает учетные данные
• sso.com устанавливает cookie для пользователя
• sso.com затем перенаправляет обратно на domain1 на специальный URL-адрес (например, domain1.com/ssologin)
• URL ssologin содержит параметр, который в основном "подписан" sso.com. Это может быть так же просто, как base64 шифрования логина с использованием общего секретного ключа.
• domain1.com принимает зашифрованный токен, расшифровывает его, использует новый идентификатор входа для входа в систему пользователя.
• domain1 устанавливает cookie сеанса для пользователя.

Теперь, следующий случай.

• Пользователь нажимает domain2.com, который следует за domain1 и перенаправляется на sso.com
• sso.com уже имеет cookie для пользователя, поэтому не отображается страница входа в систему
• sso.com перенаправляет обратно на domain2.com с зашифрованной информацией
• domain2.com регистрируется пользователем.

Это основы того, как это работает. Вы можете сделать его более надежным, более многофункциональным (например, это SSOn, но не SSOff, пользователь может "выйти из системы" domain1, но все же будет вошел в систему domain2). Вы можете использовать общедоступные ключи для подписания учетных данных, у вас могут быть запросы на передачу дополнительной информации (например, прав авторизации и т.д.) С сервера единого входа. У вас может быть более интимная интеграция, например, домены, регулярно проверяющие, что пользователь по-прежнему имеет права на сервере SSO.

Но cookie handshake через браузер с использованием перенаправления является основой, на которой основаны все эти решения SSO.

Ответ 2

Если кто-то смог сыграть человека посередине и захватить этот хеш, смогут ли они украсть перекрестный домен? Очевидно, что он должен быть сгенерирован и отправлен клиенту до того, как им понадобится его использовать. Так скажите, например:

Я играю мужчину в середине шпионажа на Джека. Джек получает доступ к domain1.com, который заставляет хеш быть подготовлен и отправлен ему, чтобы при доступе к domain2.com он мог отправить этот хеш в качестве аутентификации. Когда он обращается к domain1.com, его запрос приходит через меня, вы возвращаете страницу, я хватаю хэш и позволяю ему продолжать. Я обращаюсь к domain2.com с помощью хеша, теперь вы введете меня в domain2.com и удалили хэш. Он не мудрее, пока не попытается войти в domain2.com, и ему сказали, что его учетные данные больше не действительны.

Как вы преодолеваете это?

Ответ 3

Не было бы смысла использовать SSL для входа в междоменный домен, если вы не используете SSL для всего сеанса. Так же легко украсть файл cookie сеанса, поскольку он использует хэш в URL-адресе. Какой смысл скрывать хэш в SSL, если остальная часть сессии небезопасна.

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

Ответ 4

Это хорошее решение. Рассмотрим два момента:

Вы используете термин "хеш", но не ясно, какие данные вы будете использовать. Вместо этого используйте "nonce": большой (128-разрядный) номер, созданный криптографическим качеством RNG.

Кроме того, вы не указали это, но связь между пользователем и обоими доменами и между самими доменами должна быть безопасной. Используйте SSL для проверки подлинности серверов и сохранения конфиденциальной информации.

Ответ 5

Как насчет SEO? Похоже, что каждый запрос, прежде чем succesfull login будет перенаправлен на другой домен и обратно. Я бы сказал, что это очень уродливо. Какие заголовки вы должны отправить? 301 в SSO, а затем назад 301 на исходную страницу? Так что поисковый бот "просил" дважды изменить свой индекс для этой страницы?