Подтвердить что ты не робот

Прозрачная сессия пользователя по нескольким сайтам (однократная регистрация + однократная регистрация)

У меня есть несколько сайтов в разных доменах: example.com, example.org, mail.example.com и passport.example.org. Все сайты имеют общий внешний вид и должен использовать одну и ту же пользовательскую базу.

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

  • Единый вход. Когда пользователь подписывается на passport.example.org и посещает любой другой сайт - он должен рассматриваться как зарегистрированный.

    Записанные пользователи получают приветствие "Привет, $username" в заголовке сайта и разные меню навигации, список услуг, к которым они имеют доступ. Если он не вступил, вместо этого приветствия есть ссылка "Зарегистрироваться", указывая на passport.example.org/signon.

    Список доверенных доменов известен, поэтому это довольно просто реализовать либо с OpenID или с небольшим легким протоколом. Когда пользователь сначала сайт, я перенаправляю его на специальную конечную точку аутентификации в passport.example.org, который затем молча перенаправляет его обратно, с идентификационной информацией (или "не подписанной" ) анонимная личность). Для большинства браузеров это абсолютно прозрачно. Очевидно, что я использую значения nonce для борьбы с циклами перенаправления.

  • Единый вход. Когда пользователь нажимает "подписаться" в заголовке любого сайта в следующий раз он посещает любой сайт - его следует рассматривать как "не подписываться".

    OpenID не был разработан для этого. Моя нынешняя идея (у меня уже есть частично работающая реализация) заключается в отправке идентификатора пользователя, но "глобальный" токен сеанса и доля глобальная таблица сеансов (global_session_token ↔ отношение пользователя) в БД.

  • Поддержка роботов и cookieless-пользователей. Сайты имеют общественные зоны, которые должны быть доступным агентами-пользователями без поддержки файлов cookie.

    Из-за этого перенаправление, о котором я упоминал в (1), становится проблемой, поскольку для каждый запрос страницы, я в конечном итоге бросаю user-agent на конечную точку и обратно. Это не только запутает роботов, но и загрязнит мою базу данных сеансов мертвые-на-рождения сессии очень быстро. И я определенно не хочу показывать "эй, у вас нет файлов cookie, выйдите! ", это было бы очень грубо и разочарование. Хотя мне требуется поддержка файлов cookie для входа в систему, я хочу, чтобы пользователи свободно читали для чего нужны сайты и т.д. - без каких-либо ограничений.

    И я явно не хочу помещать идентификаторы сеанса в URL-адреса, за исключением некоторых прозрачных Перекрестные переадресации, о которых я говорил. Я считаю, что это проблема безопасности и просто вообще Bad Thing.

    И здесь у меня почти нет идей.

Хорошо, я знаю, что это сложно, но Google действительно так или иначе делает это (google.com, google. lot-of-gTLDs, gmail.com и т.д.), правильно? Так что это должно быть возможно.

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

Подводя итог: Несколько доменов без общего корня, общая пользовательская база, единый вход, однократная подписка, без файлов cookie, необходимых для анонимного просмотра.

Все сайты находятся в одной сети (но остаются на разных серверах) и частично совместно использовать одну и ту же базу данных PostgreSQL (отдыхая в разных схемах одной и той же базы данных). Большинство сайтов написаны с помощью Python/Django, но некоторые из них используют PHP и Ruby on Rails. В то время как я думаю о какой-то инфраструктуре и языке-агностике, я благодарен за указание на какие-либо реализации. Даже если я не смогу их использовать, если я получу идею, как это сделать, возможно, я смогу придумать что-то подобное.

4b9b3361

ОТВЕТЫ

Ответ 1

Хорошо, позвольте мне еще немного объяснить. (Все URL-адреса вымышлены!) Как я уже сказал, посетитель переходит к http://www.yourwebpage.com и указывает, что он хочет войти в систему. Он перенаправляется на http://your.loginpage.org?return=http://www.yourwebpage.com/Authenticated, где он должен будет указать свое имя пользователя и пароль.
Когда информация его учетной записи верна, он вернется на страницу, указанную в URL-адресе входа, но с дополнительным параметром, который будет использоваться в качестве идентификатора. Таким образом, он переходит к http://www.yourwebpage.com/Authenticated?ID=SharedSecret, где SharedSecret будет временным идентификатором, действительным в течение 30 секунд или меньше.
Когда ваша страница аутентификации будет вызвана, страница затем вызовет метод, который будет использоваться совместно с вашим веб-сайтом и сайтом loginpage.org, чтобы просмотреть информацию об учетной записи SharedSecret для получения более постоянного идентификатора. Этот постоянный идентификатор хранится в веб-сеансе yourwebpage.com и НИКОГДА не должен отображаться пользователю.
Общий метод может быть любым. Если оба сервера находятся на одной машине, они могут просто получить доступ к одной и той же базе данных. В противном случае они могут общаться с другим сервером через веб-службы. Это будет связь между серверами, поэтому не имеет значения, является ли пользователь роботом или нет поддержки файлов cookie. Эта часть не будет замечена пользователем.
Единственное, с чем вам придется иметь дело, это сеанс для пользователя. Обычно пользователям будет отправлен идентификатор сеанса, который хранится в файле cookie, но он также может быть частью URL-адреса как часть запроса GET. Это немного более безопасно, чтобы иметь идентификатор сеанса внутри запроса POST, однако, добавив скрытое поле ввода в вашу форму.

К счастью, несколько языков веб-разработки уже предоставляют поддержку сеанса, поэтому вам даже не нужно беспокоиться о том, как поддерживать сеансы и отправлять идентификаторы сеансов. Техника интересна. И вам нужно знать, что сеансы всегда должны быть временными, так как существует риск, что идентификатор сеанса будет захвачен.

Если вам приходится иметь дело с несколькими сайтами в разных доменах, вам сначала нужно будет работать с некоторыми серверами. Самым простым было бы позволить им совместно использовать одну и ту же базу данных, но лучше создать веб-сервис вокруг этой базы данных для дополнительной защиты. Убедитесь, что этот веб-сервис принимает запросы только из ваших собственных доменов, чтобы добавить еще немного дополнительной защиты.
Когда у вас есть соединения "от сервера к серверу", пользователь сможет переключаться между вашими доменами, и пока вы проходите по идентификатору сеанса в новый домен, пользователь будет входить в систему. Если пользователь использует cookie, не очень вероятно, что сеанс потеряется, что потребует снова войти в систему. Без файлов cookie есть вероятность, что пользователь снова войдет в систему, чтобы получить новый файл cookie, если идентификатор сеанса связи потеряется между страницами просмотра. (Например, посетитель отправляется в Google, а затем возвращается на ваш сайт. С помощью cookie сеанс может быть прочитан из файла cookie. Без cookie сеанс потерян, так как Google не будет передавать идентификатор сессии вперед. < br/ " >
Помните, что передача идентификатора сеанса между разными доменами является угрозой безопасности. Идентификатор сеанса может быть захвачен, что позволяет кому-то выдать себя за своего посетителя. Поэтому идентификатор сеанса должен быть недолгим и запутанным. Но даже если хакер получает доступ к идентификатору сеанса, он все равно не будет иметь полный доступ к самой учетной записи. Он не сможет перехватить связь "сервер-сервер", чтобы он не мог получить доступ к базе данных с вашей информацией о пользователе, если только он не перейдет на страницу входа в систему.

Ответ 2

AFAIK, Google использует cookie для домена Google.com. Но Google также использует OpenID, который позволяет использовать общий механизм входа. В основном это работает, перенаправляя вас на специальную страницу входа. Эта страница входа в систему обнаружит, что вы вошли в систему или нет, и если вы не вошли в систему, она попросит вас войти в систему. В противном случае она просто перенаправит вас прямо на следующую страницу.

Итак, в вашем случае пользователь откроет файл somepage.example.com, а на сеансе для этого приложения нет идентификатора входа. Таким образом, он перенаправляет пользователя на logon.example.biz, где пользователь будет входить в систему. За этой страницей также будет сеанс, и этот сеанс будет сообщать, что пользователь уже зарегистрирован. (Или нет, и в этом случае пользователь должен сначала войдите в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something, где этот sessionid будет храниться в сеансе somepage.example.com. Затем этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя он почти казался прозрачным.

В действительности, пользователь перенаправляется дважды.

Ответ 3

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

Однако вы указали некоторые сайты в домене example.com, а некоторые - в домене example.org.

Играя немного с моим взлетом Google и другими сайтами их orkut.com, похоже, что когда вы нажимаете страницу, на которой нужны учетные данные, она перенаправляет вас на общий сайт для входа в учетную запись, который затем перенаправляет вас назад на исходный сайт, предположительно передавая какой-то токен сеанса в URL-адрес. Из этого, предположительно, серверы orkut.com напрямую связывают серверы google.com, чтобы проверить токен и получить любую другую информацию пользователя.

Дополнительная информация о файлах cookie уровня домена как Rekeusted

Если у вас есть два сайта, скажем foo.example.com и bar.example.com,, вы можете установить cookie, специфичный для хоста, но вы также можете установить cookie для домена, который будет отображаться всеми хостами в домене.

Таким образом, foo.example.com может установить cookie для foo.example.com в частности, и он будет отображаться только сам по себе, но он также может установить cookie для домена example.com,, и когда пользователь перейдет на bar.example.com, они также увидит этот второй файл cookie.

Однако, если у вас также есть сайт, snafu.example.org, он не может видеть этот файл уровня домена, указанный foo, потому что example.org и example.com - это два совершенно разных домена.

Вы можете использовать файл cookie уровня домена для хранения информации о сеансе на сайтах в том же домене.

Как вы устанавливаете куки уровня домена, зависит от вашей среды разработки (у меня нет опыта работы с рельсами, извините).

Ответ 4

Для этого решения не нужен паспортный сервер.

зарегистрировались

  • Войти
  • Создать токен с зашифрованным идентификатором сеанса и другой информацией
  • Показать img с токеном из всех ваших доменов для настройки файлов cookie на нем.

Авторизация cookie

  • У вас уже есть файлы cookie для всех доменов.

Выйти

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

Я не могу попробовать это решение. Но теперь у меня такая же проблема, как у вас (SSO), и я пробую это завтра.

Ответ 5

Используете ли вы ASP.NET? Если это так, вы можете взглянуть на свойство enableCrossAppRedirects.

Ответ 6

Я использовал shibboleth для сценариев SSO и Federated Identity, но я предполагаю, что вам нужны более простые решения, упомянутые выше.

Ответ 7

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

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

Я хотел бы узнать другой способ, потому что это удары