Что интерфейс должен знать о SSO и CAS

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

Предварительное знание

Чтобы понять SSO, лучше всего иметь следующие знания. Конечно, если он не очень привычен, на чтение это не повлияет.

куки и сеансы
Одинаковая политика браузера и перекрестный домен
Понять состав системы входа

Что такое SSO и CAS?

SSO

SSO — это аббревиатура от английского Single Sign On, что переводится как единый вход. Как следует из названия, он извлекает логику входа пользователя из двух или более продуктов, так что вы можете войти в несколько продуктов одновременно, введя имя пользователя и пароль только один раз.

Например, SSO похож на пропуск, который мы покупаем, когда идем в Диснейленд.

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

Преимущества использования SSO очевидны:

Улучшить пользовательский опыт.

Возьмем, к примеру, нашу фабрику. Наша фабрика имеет два продукта, Lilac Talent Network и Lilac Garden Forum.Если вы являетесь пользователем нашей фабрики, вы не можете вводить свое имя пользователя и пароль один раз при входе в Lilac Garden Forum, и вам нужно ввести свое имя пользователя и пароль один раз для входа в Talent Network, верно?

Избегайте дублирования разработки

Если вы являетесь серверной частью нашей фабрики и каждый день перегружены задачами, вы определенно не сможете разработать один набор логик входа в Talent.com и другой на форуме, верно?

Улучшить коэффициент безопасности

Если вы работаете и обслуживаете наш завод, вы обнаружили угрозу безопасности, которую необходимо срочно устранить. Вы определенно не можете отправить электронное письмо в серверную часть огромного количества продуктов и заказать его ремонт? Что делать, если один пропущен?

В совокупности SSO — это не толькооно работает, и этонеобходимыйиз.

CAS

SSO — это просто архитектура, дизайн, а CAS — средство для реализации SSO. Оба абстрактны и конкретны. Конечно, кроме CAS, существуют и другие средства реализации единого входа, например простые файлы cookie.

Сама служба центральной авторизации CAS (Central Authentication Service) представляет собой протокол с открытым исходным кодом, который делится на версию 1.0 и версию 2.0. 1.0 называется базовым режимом, 2.0 — прокси-режимом и подходит для единого входа между приложениями, не являющимися веб-приложениями. В этой статье рассматривается только CAS 1.0, который более подробно описан ниже.

Эволюция и классификация SSO

Ниже приводится подробное описание SSO в различных сценариях, взаимосвязь между которыми постепенно совершенствуется и постепенно усложняется.

1. Система единого входа в том же домене

Как показано на рисунке, SSO в одном домене — самый простой случай.

На данный момент оба продукта находятся под одним и тем же доменным именем, и единый вход является естественным выбором. Давайте взглянем на шаги, и определение шагов здесь является основой для понимания следующего текста, не пропускайте его.

Пользователь получает доступ к продукту a и отправляет запрос на вход на фоновый сервер.
Если аутентификация при входе прошла успешно, сервер записывает информацию о входе пользователя в сеанс.
Сервер создает файл cookie для пользователя, добавляет его в заголовок ответа и записывает в браузер по мере возврата запроса. Домен этого файла cookie установлен на dxy.cn.
В следующий раз, когда пользователь посетит продукт b с тем же доменным именем, поскольку a и b находятся под одним и тем же доменным именем, которое также является dxy.cn, браузер автоматически установит предыдущий файл cookie. На этом этапе фоновый сервер может использовать файл cookie для проверки статуса входа в систему.

Фактически, этот сценарий является самой простой и традиционной операцией входа в систему. Хотя мы искусственно разделяем продукты a и b, поскольку они находятся в одной и той же области, нередко их рассматривают как разные категории одного и того же продукта. Мы не настроили независимый сервер единого входа, потому что самого фонового бизнес-сервера достаточно для выполнения функции единого входа.

2. Единый вход в тот же родительский домен

SSO с тем же родительским доменом — это простое обновление SSO с тем же доменом. Единственное отличие состоит в том, что когда сервер возвращает файл cookie, домен файла cookie должен быть установлен на его родительский домен.

Например, если адреса двух продуктов — a.dxy.cn и b.dxy.cn соответственно, то домен файла cookie может быть установлен как dxy.cn. При доступе к a и b этот файл cookie может быть отправлен на сервер, что по сути ничем не отличается от SSO на том же домене.

3. Междоменная система единого входа

Как видите, в обоих вышеприведенных случаях мы специально не настраивали SSO-сервер. Но когда два продукта находятся в разных доменах, файлы cookie не могут использоваться совместно, поэтому нам необходимо настроить отдельные серверы единого входа. В настоящее время мы реализуем SSO через стандартную схему CAS. Давайте углубимся в детали ниже:

Объясните CAS подробно

Протокол CAS 1.0 определяет набор терминов, набор билетов и набор интерфейсов.

срок:

Клиент: Пользователь.
Сервер: центральный сервер также является сервером, отвечающим за единый вход в SSO.
Служба: каждая служба, требующая единого входа, эквивалентная продукту a/b выше.

интерфейс:

/login: Интерфейс входа, используемый для входа на центральный сервер.
/logout: Интерфейс выхода, используемый для выхода из центрального сервера.
/validate: используется для проверки того, вошел ли пользователь в систему на центральном сервере.
/serviceValidate: используется, чтобы разрешить каждой службе проверять, вошел ли пользователь в систему на центральном сервере.

законопроект

TGT: Билет на выдачу билетов

TGT — это входной билет, выдаваемый CAS для пользователей. С помощью TGT пользователи могут подтвердить, что они успешно вошли в CAS. TGT инкапсулирует значение файла cookie и информацию о пользователе, соответствующую этому значению файла cookie. Когда приходит HTTP-запрос, CAS использует это значение Cookie (TGC) в качестве ключа, чтобы проверить, есть ли TGT в кеше.Если есть, считается, что пользователь вошел в систему.

TGC: файлы cookie для предоставления билетов

Сервер CAS генерирует TGT и помещает его в свою собственную сессию, а TGC — это уникальный идентификатор (SessionId) этой сессии, который размещается на стороне браузера в виде файла cookie, который является учетными данными, используемыми сервером CAS для уточнения личность пользователя.

ST: сервисный билет

ST — это билет, выдаваемый CAS пользователю для доступа к услуге. Когда пользователь обращается к сервису, сервис обнаруживает, что у пользователя нет ЗБ, и требует, чтобы пользователь обратился в CAS для получения ЗБ. Пользователь отправляет в CAS запрос на получение ST, и CAS обнаруживает, что у пользователя есть TGT, выдает ST и возвращает его пользователю. Пользователь берет ЗП для доступа к сервису, а сервис передает ЗТ в CAS для проверки.После прохождения проверки пользователю разрешается доступ к ресурсу.

Соотношение между счетами показано на рисунке ниже. Обратите внимание, что PGTIOU, PGT, PT являются содержанием CAS 2.0, и заинтересованные студенты могут ознакомиться с ними самостоятельно.

подробные шаги

Увидев это, у тебя снова немного закружилась голова? Не беда, давайте воспользуемся простым сценарием, а потом подробнее рассмотрим подробные шаги по реализации SSO с CAS, и, кстати, углубимся в понимание предложенных ранее концепций.

Начинать!

Пользователь получает доступ к продукту a, а доменное имя — www.a.cn.
Поскольку пользователь не имеет файла cookie, зарегистрированного на сервере a, сервер a возвращает перенаправление http, а перенаправленный URL-адрес является адресом сервера SSO.В то же время запрос URL-адреса указывает, что логин выполняется успешно через параметры, а затем возвращается на страницу a. URL-адрес перенаправления имеет вид sso.dxy.cn/login?service=https%3A%2F%2Fwww.a.cn.
Поскольку пользователь не несетTGC(см. выше, один из тикетов), поэтому сервер единого входа определяет, что пользователь не вошел в систему, и отображает для пользователя унифицированный интерфейс входа в систему. Пользователь выполняет операцию входа на странице SSO.
После успешного входа сервер SSO создаетTGT(другой билет), возвращая перенаправление http. Обратите внимание:

Адрес перенаправления — это страница, указанная в запросе ранее.
Запрос адреса перенаправления содержит сообщение, отправленное sso-серверомST.
Перенаправленный http-ответ содержит заголовок для записи файла cookie. Этот файл cookie представляет собой статус входа пользователя в SSO, и его значение равноTGC.

Браузер перенаправляет на продукт a. На этом этапе перенаправленный URL-адрес содержит URL-адрес, сгенерированный сервером SSO.ST.

в соответствии сST, сервер отправляет запрос на сервер SSO, и сервер SSO проверяет действительность билета. После успешной проверки сервер знает, что пользователь вошел в систему по sso, поэтому сервер создает сеанс входа пользователя, который записывается как сеанс. и записать куки в браузер. Обратите внимание, что cookie и сеанс здесь сохраняют статус входа пользователя на сервер и не имеют ничего общего с CAS.

После того, как пользователь получит доступ к продукту b, доменное имя будет www.b.cn.

Поскольку пользователь не имеет файла cookie b, зарегистрированного на b-сервере, b-сервер возвращает перенаправление http, а перенаправленный URL-адрес — это адрес сервера SSO для запроса статуса входа пользователя в SSO.

Браузер перенаправляет на SSO. Обратите внимание, что на шаге 4 браузер был написан для переносаTGCcookie, чтобы сервер единого входа мог получить его в это время, согласноTGCнайтиTGT, если найдено, считается, что пользователь уже вошел в систему по sso.

Сервер SSO возвращает перенаправление, перенаправление несетST. Обратите внимание, что ЗП здесь отличается от ЗП на шаге 4. Фактически, ЗП, генерируемое каждый раз, отличается.

группа браузераSTПеренаправить на сервер b, как в шаге 5.

Сервер b отправляет запрос на SSO-сервер в соответствии с тикетом.После того, как проверка билета пройдена, сервер b знает, что пользователь вошел в систему по sso, поэтому он генерирует сеанс b и записывает cookie b в браузер.

Как показано на рисунке, на этом весь процесс входа заканчивается. Впоследствии, когда пользователь получает доступ к a или b, cookie a/b будут передаваться напрямую, поэтому нет необходимости подтверждать SSO.

В реальной разработке может быть добавлена дополнительная логика суждения в соответствии с CAS, например, после получения ЗБ, выданного сервером CAS, если ЗБ украден хакером, а у самого клиента нет времени проверить ЗБ, хакер возьмет на себя инициативу по проверке ST. Как решить проблему? На этом этапе вы можете добавить дополнительные факторы аутентификации (такие как ip, sessionId и т. д.) при подаче заявки на ST.

Справочное чтение:

Официальная документация CAS