Вопрос по session – Прозрачный пользовательский сеанс на нескольких сайтах (единый вход + единый выход)

35

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

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

Single sign-on. When user signs on at passport.example.org and visits any other site — he should be treated as logged in.

Logged in users get “Hello, $username“ greeting in site header and different navigation menu, listing services they have access to. If he's not signed in, instead of greeting there's a “Sign on” link, pointing to passport.example.org/signon.

The list of trusted domains is known, so this is fairly simple to implement either with OpenID or with some homebrewn lightweight protocol. When user first hits the site, I'm redirecting him to special authentication endpoint at passport.example.org, which then silently redirects him back, with identity information (or “not signed on” anonymous identity) included. For most browsers this is completely transparent. Obviously, I'm using nonce values to fight redirection loops.

Single sign-off. When user clicks “sign off” in the header of any site the next time he visits any site — he should be seen as “not sign on”.

OpenID was not designed for this. My current idea (I already have a partially-working implementation) is to send not user identity, but “global” session token and share global sessions table (global_session_token ↔ user relation) in DB.

Robots and cookieless-users support. Sites are having public areas, which should be accessible by user-agents without any cookie support.

Because of this, redirection I've mentioned in (1) becomes a problem, because for every single page request, I'll end up throwing user-agent to auth endpoint and back. Not only this will confuse robots, but it will pollute my session database with dead-on-birth sessions very quickly. And I definitely don't want to display “hey, you don't have cookies enabled, go away!” page, that'd be extremely rude and disappointing. While I require cookie support to login, I want users to freely read what the sites are for and so on — without any restrictions.

And I explicitly don't want to put session IDs in URLs except for some transparent cross-domain redirections I've mentioned. I believe doing such is a security problem and just generally a Bad Thing.

And here I'm almost out of ideas.

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

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

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

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

Нет, это не сложно. Это просто трюк, как карточные фокусы. Как только вы знаете, как это просто. :-) Wim ten Brink

Ваш Ответ

7   ответов
1

Войти в систему

Login Create token with encrypted session id and other info Show img with token from all you domains for setting cookies on its.

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

You already have cookies on all domains.

выход

Clear cookie Destroy session Clear relation user id with last session id in DB (I think you save session id in user table for rising up session by cookie)

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

31

позвольте мне объяснить немного дальше. (Все 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 существует вероятность того, что пользователю придется снова войти в систему, чтобы получить новый файл cookie, если идентификатор сеанса теряется между страницами просмотра. (Например, посетитель посещает Google, а затем возвращается на ваш сайт. С помощью cookie-файла сеанс может быть прочитан из cookie-файла. Без cookie-файла сеанс теряется, поскольку Google не передает идентификатор сеанса вперед.

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

Error: User Rate Limit Exceeded drdaeman
1

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

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

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

More Info On Domain Level Cookies as Reqeusted

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

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

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

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

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

5

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

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

На самом деле, пользователь перенаправляется дважды.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded drdaeman
Error: User Rate Limit Exceeded
0

так и для федеративной идентификации, но я предполагаю, что вам нужны более простые решения, чем упомянутое выше.

1

enableCrossAppRedirects имущество.

Error: User Rate Limit Exceeded drdaeman
-4

способный плагин rails, чтобы сделать это было бы здорово.

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded

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