Полное название SSO на английском языке — Single Sign On. когда мы ищем单点登录, вы найдете много статей, но эти статьи, как правило, основаны на общем описании сценария, который обычно более сложен в соответствующей бизнес-среде. В этой статье я опишу решение для реализации единого входа в конкретных сценариях.
Полное название SSO на английском языке — Single Sign On. SSO заключается в том, что в системах с несколькими приложениями пользователям необходимо войти в систему только один раз, чтобы получить доступ ко всем взаимно доверенным системам приложений. Он включает механизмы для сопоставления этого основного входа с входами того же пользователя в других приложениях. Это одно из самых популярных решений для корпоративной бизнес-интеграции.
задний план
На ранней стадии развития предприятия, как правило, сайт доменных имен может нести независимые услуги. Однако по мере того, как компании осваивают новые виды бизнеса, они будут подавать заявки на новое доменное имя для выполнения функций этих новых предприятий, с одной стороны, чтобы выделить их, а с другой стороны, чтобы соответствовать нормативным требованиям. И нужно получить через пользователя систему исходного сайта в этом режиме. Существует два основных типа новых независимых доменных имен:
- Исходный сайт — www.a.com, а новое независимое доменное имя — new.a.com;
- Исходный сайт — www.a.com, а новое независимое доменное имя — www.b.com;
Для первого сценария мы обычно используем общиеsessionТаким образом, пользователи могут переключаться между разными доменными именами без необходимости повторного входа в систему. Конкретная реализация в основном предназначена дляcookiesо статусе входа пользователя вsessionidДомен настроен на.a.com.
Этот сценарий относительно прост, и достаточно переключаться между старым и новым режимами. Поскольку по умолчанию домен sessionId равенwww.a.com,Если вы посещали сайт www.a.com ранее, и домен не очищается при входе в системуwww.a.comsessionid, затем доступwww.a.comСайт, браузер будет сеять два одно и то же имя, переданное на сервер, потому что этоkey-valueВ виде , сервер не может различить, какой новый, а какой старый, если взять старый, то в это время невозможно получить статус входа пользователя. Чтобы решить эту проблему, вам нужно только установить исходный домиан в качествеwww.a.comустановить срок действия или использовать новый ключ sessionId. Проверьте этоВведение в set-cookies.
Этот сценарий больше используется на нашем мобильном сайте. Например, основной сайт — www.a.com, а мобильный — m.a.com.
#设置domian为.a.com的sessionId
Set-Cookie: sessionId=a3fWa; Domain=.a.com; Secure; HttpOnly
#将domian为www.a.com的sessionId置为过期
Set-Cookie: sessionId=a3fWa; Domain=www.a.com; expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly
Далее мы в основном опишем второй сценарий. Для этого сценария главное требование, чтобы пользователь не воспринимал, и необходимо выполнить следующие пункты:
- После входа на сайт а синхронизируйте статус входа с сайтом б;
- После доступа к сайту b без страницы входа вам необходимо активно синхронизировать статус входа на сайт a;
- Когда для доступа к сайту b требуется страница входа, вам нужно перейти на сайт a для синхронизации состояния входа;
Процесс 1: после входа на сайт а синхронизируйте статус входа с сайтом б.
Выше приведена временная диаграмма активного состояния входа в систему синхронизации. Билеты на иллюстрации в основном хранятся вredis, вы также можете сохранить его на другом носителе или даже в оперативной памяти приложения, но следует отметить, чтоБилеты должны быть действительны один раз и должны быть удалены после использования.. Поскольку наш сайт b здесь также находится под собственным контролем, а производительность чтения и записи Redis также значительно выше, a и b подключаются и читают один и тот же Redis. Если сайт b не находится под контролем, запрос может быть инициирован в фоновом режиме сайта b к сайту a, чтобы узнать о действительном статусе заявки. Конкретный процесс выглядит следующим образом:
- Пользователь посещает страницу входа на сайт a.com;
- Введите имя пользователя и пароль для входа в систему, a.com проверит пользователя в фоновом режиме и после успеха создаст сеанс сайта и создаст билет для помещения в Redis;
- После успешного входа на страницу входа получите билет и отправьте междоменный запрос (JSONP или изображение) на b.com;
- После того, как сайт b получит тикет, проверьте, существует ли редис, есть ли сессия для сайта b и удалите тикет;
- После возврата междоменного запроса продолжите другие операции, такие как переход в пользовательский центр, домашнюю страницу и т. д.
Процесс 2: сайту b не нужно входить на страницу для активной синхронизации статуса входа сайта a
Поскольку сайты a и b независимы друг от друга, предполагается, что время истечения соответствующего сеанса составляет полчаса.Если сайт a всегда находится в состоянии посещения, сеанс будет продолжать жить, но доступ к сайту b не осуществлялся в течение более 30 минут, и срок действия сеанса истек. При посещении сайта b у вас будет эта сцена. Конкретный процесс выглядит следующим образом:
- Пользователям не нужна страница входа для доступа к b.com;
- Если текущий пользователь сайта не вошел в систему, инициируйте асинхронный запрос JSONP к a.com;
- Если a.com не авторизован, ничего не делайте. Если вы уже вошли в систему, сгенерируйте информацию о билете, как в предыдущем процессе;
- После получения билета запросите у сайта b синхронизацию статуса входа, и сайт b сгенерирует сеанс;
- Активно обновлять текущую страницу после успешной синхронизации.
Процесс 3: Сайт Б должен войти в систему на сайте А, чтобы активно перейти на сайт А для синхронизации состояния входа;
Как и процесс 2, этот сценарий также вызван тем, что в течение длительного времени вы не посещаете и не входите на сайт b. В отличие от процесса 2, этот сценарий представляет собой метод 302 прямого перехода на страницу синхронизации. Это чистая статическая страница, пожалуйста, используйте второй процесс, конкретный процесс выглядит следующим образом:
- Пользователю необходимо войти на страницу, чтобы получить доступ к b.com, и вернуть 302, чтобы перейти на страницу синхронизации статуса сайта a;
- Страница синхронизации статуса сайта а оценивает статус входа на сайт и переходит на страницу входа сайта а, если он не зарегистрирован. Процесс входа такой же, как и процесс 1. После успешного входа требуется страница входа. перейти на сайт b;
- Статус входа в систему синхронизируется с сайтом b через статус входа JSONP, и сайт b создает сеанс;
- После успешной синхронизации сайта b страница входа необходима для перехода на сайт b.com.
Суммировать
Вышеупомянутый процесс в основном заключается в решении различных сценариев для реализации процесса SSO, который можно разделить на две категории в зависимости от различных инициаторов: активная синхронизация и пассивная синхронизация. Активная синхронизация предназначена для получения билета с сайта аутентификации и синхронизации собственного состояния входа, а пассивная синхронизация — для синхронизации состояния входа с сайта аутентификации с текущим сайтом.
Как правило, онлайн-материалы имеют сайт, посвященный аутентификации и входу в систему.Например, сайты a.com и b.com получают статус аутентификации от sso.a.com. На самом деле, в этой статье сайт a используется как сайт sso, что в принципе согласуется.
Чтобы внедрить этот набор решений, коллегам по развитию бизнеса не нужно обращать внимание на эту часть деталей реализации и писать соответствующий код синхронизации, мы вписали его в общий фреймворк, и в основном сделали следующие две вещи:
- Инкапсулировать сценарий входа в систему (поддержка ссылки npm, прямая упаковка веб-пакета), выполнять активную синхронизацию сайта после входа в систему, коллеги по бизнесу напрямую вызывают метод и выполняют другие операции в функции обратного вызова, когда им нужно войти в систему;
- Используйте механизм шаблонов, такой как ejs или pug, чтобы поместить процесс синхронизации процесса 2 в общий шаблон, а другие страницы создаются на основе общего шаблона.
Для получения дополнительной информации о сертификации SSO см.OAuth2Этот процесс будет более зрелым с точки зрения безопасности для аутентификации между ненадежными сайтами, и это также процесс аутентификации, который в настоящее время принят WeChat.
К вашему сведению:
Единого входа (SSO) достаточно, чтобы прочитать эту статью
Подробное объяснение методов реализации единого входа SSO в трех ситуациях.
Авторизация на веб-странице WeChat