Прозрачный сеанс пользователя по нескольким сайтам (единая точка входа + единственный выход)
попробуйте это: http://maven.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/
эта ссылка содержит переносимые почтовые дистрибутивы для всех версии.
7 ответов
Что ж, тогда позвольте мне объяснить немного подробнее. (Все 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 не передает идентификатор сеанса вперед.
Имейте в виду, что передача идентификаторов сеанса между разными доменами представляет собой угрозу безопасности. Идентификатор сеанса может быть взломан, таким образом, давая возможность кому-то другому выдать себя за вашего посетителя. Таким образом, идентификаторы сеанса должны быть недолговечными и скрытыми. Но даже если хакер получит доступ к идентификатору сеанса, он все равно не получит полного доступа к самой учетной записи. Он не сможет перехватить межсерверную коммуникацию, поэтому он не сможет получить доступ к базе данных с вашей пользовательской информацией, если он не перейдет на страницу входа напрямую.
Если все ваши приложения находятся в одном домене, это не слишком сложно, потому что вы можете использовать cookie уровня домена для обработки сеанса контроль. (Управление сеансом без файлов cookie сложно, но возможно, но сложно.)
Однако вы указали некоторые сайты в домене example.com, а некоторые - в домене example.org.
Немного поиграем. с моим вздохом Google и других их сайтов orkut.com, похоже, что когда вы попадаете на страницу, требующую учетных данных, она перенаправляет вас на общий сайт для входа в учетную запись, который затем перенаправляет вас обратно на исходный сайт, предположительно передача какого-то токена сеанса в URL-адресе. Исходя из этого, предположительно, серверы orkut.com взаимодействуют напрямую с серверами google.com для проверки токена и получения любой другой необходимой информации о пользователе.
AFAIK, Google просто использует cookie для домена "Google.com". Но Google также использует OpenID, который позволяет использовать общий механизм входа в систему. По сути, это работает путем перенаправления вас на специальную страницу входа. Эта страница входа определит, вошли вы в систему или нет, и если вы Если вы не вошли в систему, вам будет предложено войти в систему. В противном случае он просто перенаправит вас прямо на следующую страницу.
Итак, в вашем случае пользователь откроет somepage.example.com, а сеанс для этого приложения не имеет входа МНЕ БЫ. Таким образом, он перенаправит пользователя на logon.example.biz, где пользователь войдет в систему. За этой страницей также будет сеанс, и этот сеанс сообщит, что пользователь уже вошел в систему. (Или нет, в этом случае пользователь должен сначала войдите в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something, где этот идентификатор сеанса будет сохранен в сеансе somepage.example.com. Тогда этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя это будет почти прозрачным.
На самом деле, пользователь перенаправляется дважды.
Итак, в вашем случае пользователь откроет somepage.example.com, а сеанс для этого приложения не имеет идентификатора входа. Таким образом, он перенаправит пользователя на logon.example.biz, где пользователь войдет в систему. За этой страницей также будет сеанс, и этот сеанс сообщит, что пользователь уже вошел в систему. (Или нет, в этом случае пользователь должен сначала войдите в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something, где этот идентификатор сеанса будет сохранен в сеансе somepage.example.com. Тогда этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя это будет почти прозрачным.
На самом деле, пользователь перенаправляется дважды.
Итак, в вашем случае пользователь откроет somepage.example.com, а сеанс для этого приложения не имеет идентификатора входа. Таким образом, он перенаправит пользователя на logon.example.biz, где пользователь войдет в систему. За этой страницей также будет сеанс, и этот сеанс сообщит, что пользователь уже вошел в систему. (Или нет, в этом случае пользователь должен сначала войдите в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something, где этот идентификатор сеанса будет сохранен в сеансе somepage.example.com. Тогда этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя это будет почти прозрачным.
В действительности, пользователь перенаправляется дважды.
За этой страницей также будет сеанс, и этот сеанс сообщит, что пользователь уже вошел в систему. (Или нет, и в этом случае пользователь должен сначала войти в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something где этот sessionid будет храниться в сеансе somepage.example.com. Тогда этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя это будет почти прозрачным.В действительности, пользователь перенаправляется дважды.
За этой страницей также будет сеанс, и этот сеанс сообщит, что пользователь уже вошел в систему. (Или нет, и в этом случае пользователь должен сначала войти в систему.) Затем он перенаправляет пользователя somepage.example.com?sessionid=something где этот sessionid будет храниться в сеансе somepage.example.com. Тогда этот сеанс также будет знать, что пользователь вошел в систему, и для пользователя это будет почти прозрачным.В действительности, пользователь перенаправляется дважды.
Are you using ASP.NET? If so, you might want to have a look at the enableCrossAppRedirects property.
Для этого решения не нужен сервер паспортов.
Вход
- Вход
- Создать токен с зашифрованным идентификатором сеанса и другой информацией
- Показать img с токеном со всех ваших доменов для установки файлов cookie на его.
Авторизация с помощью cookie
- У вас уже есть файлы cookie на всех доменах.
Выйти
- Очистить cookie
- Удалить сеанс
- Очистить идентификатор пользователя связи с идентификатор последнего сеанса в БД (я думаю, вы сохраняете идентификатор сеанса в таблице пользователей для повышения сеанса с помощью cookie)
Я не могу попробовать это решение. Но теперь у меня такая же проблема, как у вас (SSO), и я попробую завтра.
Я использовал shibboleth как для сценариев единого входа, так и для федеративной идентификации, но полагаю, что вам нужны более простые решения, чем упомянутые выше.
Кросс-доменный плагин rails для этого был бы потрясающим.
Я хотел бы сделать это, единственный способ, который я мог придумать, это заставить пользователя загрузить панель инструментов или какое-то маленькое воздушное приложение, которое автоматически обрабатывало бы вход в систему для меня.
Я хотел бы знать другой способ, чтобы это дуло