Параметры межсайтовой аутентификации на отдельных доменах - PullRequest
0 голосов
/ 10 февраля 2011

Мы рассматриваем систему аутентификации для очень временного веб-сайта, который должен проходить аутентификацию с другого сайта.Подводя итог, у нас есть два сайта на совершенно разных доменах.foo.com - это основной сайт, который всегда будет существовать (и уже существует).Это главное место, куда пользователи заходят и заходят на этот сайт, и там делают что-то в своем состоянии входа.Этот сайт будет изменен в ближайшее время, чтобы иметь ссылку на bar.com.Когда пользователь, который вошел на foo.com, щелкает ссылку на bar.com, он должен волшебным образом войти на bar.com.(Я знаю, это звучит как кошмар безопасности, но bar.com - это просто временный сайт для короткого окна, которое люди на foo.com будут использовать в течение дня или двух).Нам не разрешено входить на сайт bar.com, все это должно происходить на foo.com.Мы попытались найти решения здесь и хотим еще, если есть какие-то хорошие.Он наш:

  1. На bar.com, проверьте реферер, если он на foo.com, сделайте так, чтобы пользователь вошел в систему. Это очень небезопасно и может быть легко подделано.Мы знаем.

  2. При входе на foo.com ссылка на bar.com содержит специальную зашифрованную строку запроса, представляющую сеанс пользователя на foo.com.Если щелкнуть ссылку на bar.com, пусть bar.com возьмет эту строку запроса и использует веб-сервис, чтобы передать ее обратно на foo.com, и foo.com ответит, независимо от того, является ли это допустимым сеансом или нет.Это более безопасно, чем 1 выше, потому что информация о сеансе строки запроса зашифрована, и вызов веб-службы гарантирует, что это законный сеанс.

Есть ли здесь другие варианты?Позвольте мне еще раз повторить, что мы хотели бы хорошее решение, которое было бы более безопасным, чем 1 выше, но это для временного сайта, доступ к которому имеют только определенные люди.Мы понимаем, что это звучит странно, но для очень специфического сайта, у которого будет короткая жизнь для определенной цели.В соответствии с требованиями, нам нужно, чтобы пользователи заходили только на исходный сайт.Заранее благодарим за любые советы или указатели по этому вопросу.

Ответы [ 2 ]

1 голос
/ 10 февраля 2011

Я бы рискнул сказать, что вариант 2 - это ваша лучшая ставка, учитывая, что:

  1. foo.com содержит информацию о исходной сессии
  2. foo.com предоставляет защищенную службудля аутентифицированного вызова, который может быть сделан с bar.com для целей проверки
  3. bar.com передается токен, который содержит токен аутентификации некоторой формы
  4. , затем токен передается защищенномуперезвоните на foo.com, используя заранее определенные учетные данные, которые являются подлинными только для соединения между foo.com и bar.com

Хороший пример единого входа (SSO) для разных доменов: Part1 & Часть 2

0 голосов
/ 10 февраля 2011

Я думаю, что второй вариант - хорошее решение, вы могли бы обойтись даже без веб-службы: сделайте ссылку на bar.com включающей параметры запроса, содержащие имя пользователя (или любой другой контекст, который вам нужен для пользователя), одноразовый номер (например,случайное число) и код аутентификации (например, HMAC или цифровая подпись) для объединения имени пользователя, IP-адреса пользователя и одноразового номера.Тогда вам не нужно обмениваться данными между двумя серверами, вам нужно только предварительно поделиться данными проверки (ключ HMAC / открытый ключ проверки подписи), и вы можете проверить информацию непосредственно на втором сервере (сохраняя информацию об использованных ранееодноразовые, чтобы предотвратить повторные атаки, но, вероятно, они не представляют большой проблемы в вашем сценарии, я думаю).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...