Пересеките Доменный Вход в систему - Как зарегистрировать пользователя в автоматически при передаче от одного домена до другого

Мы предлагаем много онлайн-сервисов. Мы обязаны разрабатывать систему, которая предоставляет быстрый/простой опыт пользователям, если они передаются из одной службы (на domain1.com) к другому сервису (на domain2.com).

Существует ли безопасный и надежный способ зарегистрировать пользователя в автоматически, после того как он был передан новой службе?

Вопль во мне, если решение ниже абсолютно небезопасно/неправильно.

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

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

Пользователь будет передан domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

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

Мог что-то на основе OpenID или OAuth достигает тех же результатов?

49
задан Boann 16 July 2019 в 10:25
поделиться

3 ответа

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

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

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

  • Пользовательские хиты domain2.com, который следует domain1 и перенаправляет к [1 115]
  • sso.com уже, имеют cookie для пользователя, не представляет страницу входа в систему
  • sso.com, перенаправления назад к [1 118] с зашифрованными данными
  • domain2.com входят в систему пользователь.

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

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

125
ответ дан bluish 7 November 2019 в 11:21
поделиться

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

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

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

8
ответ дан bluish 7 November 2019 в 11:21
поделиться

Это - хорошее решение. Вот два вопроса для рассмотрения:

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

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

6
ответ дан erickson 7 November 2019 в 11:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: