Прозрачного сеанс пользователя в течение нескольких сайтов (единый вход + единый вход-офф)

Question

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

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

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

   авторизированные пользователи получают «Hello, $username«приветствие в заголовке сайта и различных меню навигации, список услуг, которые они имеют доступ. , Если он не вошел, вместо приветствия есть ссылка «Войти», указывая на passport.example.org/signon.

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

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

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

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

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

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

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

Хорошо, я знаю, что это трудно, но на самом деле Google делает это как-то с (google.com, google.много-оф-оДВУ, gmail.com и так далее), не так ли? Так что это должно быть возможно.

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

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

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

Answer 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 секунд или меньше.
Когда ваша страница авторизации вызывается, страница будет вызывать метод, совместно используемый yourwebpage.com и loginpage.org, для поиска информации об учетной записи SharedSecret для получения более постоянного идентификатора. Этот постоянный идентификатор хранится в веб-сеансе yourwebpage.com и НИКОГДА не будет отображаться пользователю.
Общий способ может быть любым. Если оба сервера находятся на одной машине, они могут просто получить доступ к одной и той же базе данных. В противном случае они могут общаться с другим сервером через веб-службы. Это будет связь между серверами, поэтому не имеет значения, является ли пользователь роботом или нет поддержки файлов cookie. Эта часть не будет замечена пользователем.
Единственное, с чем вам придется иметь дело, это сеанс для пользователя. Обычно пользователям будет отправлен идентификатор сеанса, который хранится в файле cookie, но он также может быть частью URL-адреса как часть запроса GET. Более безопасно иметь идентификатор сеанса внутри запроса POST, однако, добавив скрытое поле ввода в вашу форму.

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

Если вам нужно иметь дело с несколькими сайтами в разных доменах, вам сначала нужно будет работать с некоторыми соединениями «сервер-сервер». Самым простым было бы позволить им использовать одну и ту же базу данных, но лучше создать веб-сервис вокруг этой базы данных для дополнительной защиты. Убедитесь, что эта веб-служба принимает запросы только из ваших собственных доменов, чтобы добавить еще немного дополнительной защиты.
Если у вас есть соединения между серверами, тогда пользователь сможет переключаться между вашими доменами и до тех пор, пока вы передаете идентификатор сеанса в новый домен, пользователь будет вошел в систему.Если пользователь использует куки-файлы, маловероятно, что сеанс потеряется, что потребует снова войти в систему. Без файлов cookie есть вероятность, что пользователь снова войдет в систему, чтобы получить новый файл cookie, если идентификатор сеанса связи потеряется между страницами просмотра. (Например, посетитель отправляется в Google, а затем возвращается на ваш сайт. С кукисом сессия может быть прочитана из файла cookie. Без cookie сеанс потерян, так как Google не будет передавать идентификатор сессии вперед.

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Дополнительная информация о Домен Cookies в Reqeusted

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

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

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

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

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

Answer 5

Для этого решения не требуется passpor t сервера.

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

1. Войти
2. Создать маркер с зашифрованным идентификатором сессии и другой информацией
3. Показать Img с маркером из всех вас доменов для установки куки на ИТС.

Авторизация по куки

1. У вас уже есть куки на всех доменах.

Вход из

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

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

Answer 6

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

Answer 7

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

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

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