sso что это такое

Как Search Space Optimization (SSO) помогает привлекать больше трафика и увеличивать продажи

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

Традиционное SEO уже не столь эффективно. С каждым годом поисковая выдача всё больше состоит из объявлений контекстной рекламы, принадлежащих поисковикам сервисов вроде Яндекс.Услуг и «Дзена», а также всевозможных агрегаторов, маркетплейсов и других крупных площадок. Ограничиваться в таких условиях борьбой за позиции в топе — не лучшее решение. Вместо того, чтобы конкурировать с сервисами и платформами в выдаче ПС, их можно использовать при продвижении вашего проекта. Такой подход называется оптимизацией поискового пространства или SSO (Search Space Optimization).

В выдаче поисковых систем (ПС) всё больше места получают принадлежащие им же сервисы, а крупные маркетплейсы и прочие агрегаторы успешно вытесняют из неё обычные интернет-магазины. Что уж говорить о контекстной рекламе, которую и вовсе скоро будет не отличить от органической выдачи. В результате большинству сайтов в сравнении с былыми масштабами теперь приходится довольствоваться крохами трафика из поисковых систем, так как попасть на первую страницу выдачи им крайне сложно, а оказаться на её первом экране уже и вовсе не представляется возможным.

Очевидно, позитивных изменений вскоре ждать не приходится: Яндекс количество своих сервисов в выдаче лишь увеличивает, а агрегаторам из неё исчезать и вовсе не с чего — их там, напротив, появляется всё больше. Чтобы не упускать выгоду, веб-мастерам и владельцам интернет-магазинов нужно адаптироваться к новым условиям и научиться работать с недавними «конкурентами» по выдаче. В отличие от SEO, такой подход вместо вывода сайта в топ предполагает регистрацию и продвижение в тех сервисах и агрегаторах, которые уже прочно удерживают высокие позиции. В результате с их помощью можно получить и посетителей, и клиентов.

Под термином «поисковое пространство» подразумеваются все сервисы и порталы, где пользователи могут узнать о вашей компании. Таким образом, к поисковому пространству относится как ваш собственный сайт и ПС, так и агрегаторы вроде Авито и Zoon, и сервисы самих поисковых систем, например, карты у Яндекс и Google, «Дзен», «Кью» и другие.

Предположим, вам нужно продвинуть сайт компьютерного мастера в Москве. Если ввести в Яндекс соответствующий запрос, первая страница выдачи, помимо контекстной рекламы, будет сплошь забита всевозможными сервисами — тут и Яндекс.Услуги, и Авито, и Профи.ру, и 2ГИС.

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

Оптимизация поискового пространства означает работу по трём направлениям: развитие сайта, SEO и работа с сервисами и платформами из поисковой выдачи. Для работы с последними нужна отдельная стратегия. Сформировать её можно следующим образом:

Обычно стратегия SSO предполагает работу с площадками следующих типов:

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

Наверняка, вы и сами не раз замечали, что статьи в Яндекс.Дзене регулярно оказываются на первых страницах выдачи по самым разнообразным информационным запросам. Поэтому для интернет-магазинов и других компаний «Дзен» — это в первую очередь отличная возможность начать привлекать трафик из поиска не только по коммерческим ключам. При работе с этой площадкой помните, что её пользователи предпочитают лёгкие и интересные материалы небольшого объёма, ориентированные на широкую аудиторию. Что касается формата, тут популярны подборки, рекомендации, истории и кейсы.

Учтите, что «Дзен» подходит не всем, особенно реклама на Яндекс Дзене. Комфортней всего здесь себя чувствует бизнес со сложными, специфичными или дорогими товарами, по которым потенциальным покупателям требуется предварительная консультация. Благодаря «Дзену» можно повысить лояльность к бренду, охватить новую аудиторию и продемонстрировать свою экспертность с помощью статей.

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

Пользователи этой площадки задают вопросы и дают на них ответы. Что касается компаний, для них это хорошая возможность продемонстрировать экспертизу и сформировать доверие к бренду. Для этого достаточно развёрнуто отвечать на популярные вопросы, содержащие в себе информационные запросы. Пользователи, посмотрев ваши ответы, смогут перейти не только на вашу страницу в «Кью», но и к вам на сайт, а также сразу оформить заказ.

Как и «Дзен», Яндекс.Кью подходит не каждому бизнесу. Во-первых, продвигаться с его помощью имеет смысл интернет-магазинам с карточками товаров, ведь ссылки на них можно ставить прямо в ответах на вопросы. Во-вторых, «Кью» хорошо подходит бизнесу со сложными товарами, а также с длинным циклом продажи.

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

Для интернет-магазинов, ассортимент которых насчитывает тысячи товаров, а цены находятся на низком или среднем уровне, Яндекс.Маркет — эффективный способ охватить новую аудиторию и увеличить продажи. С помощью этого сервиса миллионы пользователей поисковика регулярно выбирают и сравнивают товары из разных магазинов. Достаточно разместить в этом маркетплейсе свои предложения, чтобы начать часто показываться в выдаче Яндекса.

С помощью «Услуг» пользователи находят исполнителей для самых разных задач. Сервис получает и направляет запросы исполнителям, которыми бывают и компании, и самозанятые работники. Регистрация в «Услугах» будет не лишней, даже когда сайт компании и так хорошо ранжируется Яндексом. На страницу следует добавить логотип компании, адрес, описать ваши преимущества и привести информацию об оказываемых услугах и ценах. После того, как модератор проверит профиль организации, страница появится в результатах внутреннего поиска по сервису.

С помощью «Карт» можно привлечь пользователей, которые находятся в поиске товаров и услуг в конкретной геологации. Для начала работы с сервисом нужно пройти регистрацию, перечислить три основных направления деятельности компании, указать реквизиты, загрузить прайс-лист и фотографии офисного здания. Это позволит вашему сайту корректно ранжироваться в сервисе, однако, попадёт ли он в информационный блок будет зависеть от разных факторов. Одним из самых важных среди них являются отзывы, а именно их количество и тональность. Чтобы привлекать больше пользователей с помощью Яндекс.Карт, подумайте, как вы можете мотивировать клиентов писать развёрнутые отзывы о вашей компании (например, с помощью скидок на следующие покупки), а также не забывайте своевременно на них отвечать.

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

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

Источник

Межсайтовая авторизация (SSO)

Есть задача — организовать межсайтовую авторизацию между проектами, размещенными на разных доменах (site1.com, site2.com). Пользователь автризовавшись на одном проекте, авторизовывается на всех (Single Sign On). Тоже самое с кнопкой выход (Single Sign Out). Доступ к хранилищу сессий и к базе есть у каждого проекта.

За два дня перелопатил множество статей и обсуждений. Вывод — стандартного решения для моего случая найти не удалось (интранет решения и сайты с четко разделенной открытой/закрытой зоной я не рассматривал).

Update: Продолжение истории Межсайтовая авторизация 2.

Вариант 1

Основой этого варианта является централизованный сервер авторизации и HTTP редиректы.

1. Пользователь вводит логин пароль и постит форму.
2. Мы шифруем логин + пароль + урл возврата + урл при неверных логине/пароле + время жизни (не более 30 секунд) c возможность расшифровки и получаем уникальный токен.
3. Делаем редирект на сервер авторизации передавая в параметре полученный токен.
4. Сервер авторизации его расшифровывает и проводит авторизацию.
5. Авторизация прошла: ставим куку, поднимаем сессию и генерируем токен (ид сессии и время жизни токена). Логин/пароль не верный: вместо токена — флаг что авторизация провалилась.
6. Сервер авторизации делает редирект на обратный урл с полученным параметром.
7. Расшифровываем токен и ставим куку.
8. Делаем редирект сами на себя чтобы очистить урл в адресной строке.

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

1. Пользователь заходит на сайт. Проверяем если ли кука, если есть поднимаем сессию, если нет, то идем дальше.
2. Делаем редирект на сервер авторизации с шифрованным адресом возврата.
3. Сервер авторизации проверяет есть ли кука.
4. Если есть то шифруем токен с ид сессии и временем жизни токена если нет то флаг что куки нету.
5. Делаем редирект обратно с полученным параметром.
6. Расшифровываем токен и ставим куку.
7. Делаем редирект сами на себя чтобы очистить урл в адресной строке.

Выход

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

Из плюсов хочу заметить что все работает с использованием обычного протокола HTTP без применения дополнительных технологий.
Минус достаточно большой и связан с авторизацией по куки: если у пользователя отключены куки или к нам зашел робот то начинается кошмар: на каждый его запрос будет 3 редиректа + создаваться новая сессия.

Есть 2 варианта решения этой проблемы:
1. Вместо редиректа подключать JavaScript с сервера авторизации, который, если там есть кука, будет поднимать сессию и ставить куку на сайт. Но у этого решения тоже есть минусы: как я понял, есть проблемы с Safari и авторизация по куки не будет работать если отключен JavaScript.
2. Попытаться запалить того кто не сохраняет куки (в основном это роботы). Можно отпарсить XML файл с сайта www.user-agents.org и засунуть его в какой-нибудь MemcacheDb и проверять при каждом запросе. Либо попробовать ставить куку, если не получилось то сохранять IP (можно с User Agent) в том же MemcacheDb и тоже проверять при каждом запросе. Можно комбинировать оба приема.

Вариант 2

Особенности этого варианта, что не нужен сервер авторизации и не страшны роботы, а также работает с отключенным JavaScript. Хотя решение честно говоря не самое красивое.

1. Пользователь вводит логин/пароль и постит форму.
2. Авторизуем, ставим куку, поднимаем сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
5. Показываем по одной однопиксельной картинке для каждого домена с токеном в урле.
6. Картинки (скрипты которые отдают картинки) расшифровывают токены и ставят куки на каждом домене (не забываем отдавать заголовок P3P:CP=«IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT»).

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

Куки уже стоят на всех доменах.

Выход

1. Удаляем куки и сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
4. Показываем картинки с каждого домена с токеном в урле.
5. Картинки расшифровывают токен и удаляют куки.

Из минусов: не работает авторизация по куки если отключены картинки. Каждый домен/проект должен знать о всех остальных.

Я сам не выбрал какой вариант использовать, поэтому и решил обсудить эту тему с вами, дабы найти проблемные места и прийти к оптимальному решению.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SSO (Single Sign-On)

Таким образом ключевым моментом здесь является то, что пользователю требуется войти в систему для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу. [Источник 1]

Содержание

Общая схема систем единого входа

Подход технологии единого входа продемонстрирован на схеме. При этом подходе система может собирать от пользователя (в рамках первичного входа) все идентификационные и аутентификационные данные, необходимые для поддержки аутентификации этого пользователя на каждом из вторичных доменов, с которыми ему потенциально может понадобиться взаимодействовать. Эти предоставленные пользователем данные впоследствии используются сервисами единого входа в пределах первичного домена для поддержки аутентификации этого конечного пользователя на каждом из вторичных доменов, с которыми ему реально требуется взаимодействовать.

Информация, предоставленная конечным пользователем в рамках процедуры входа в первичный домен, может использоваться для поддержки входа во вторичный домен несколькими способами:

С точки зрения управления, модель единого входа предоставляет единый интерфейс управления учётными записями пользователей, через который все домены могут управляться координированным и синхронизированным способом.

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

Основные достоинства и недостатки SSO

Методы SSO

Технология единого входа включает в себя следующие методы:

Основные преимущества SSO

Протоколы, обеспечивающие технологию единого входа

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

Протоколы семейства WS-

Данный протокол основывается на стандартах WS-Security и WS-Trust и описан в спецификации WS-Federation Passive Requestor Profile, в которой представлены механизмы для запроса, обмена и выдачи маркера безопасности в ситуации с пассивным клиентом. Определение «пассивный клиент» подразумевает наличие на компьютере пользователя только веб-браузера, так как взаимодействие между пользователем, Центр Идентификации и Целевое Приложение (веб-сервер, предоставляющий ресурсы) происходит в пределах функциональности базы HTTP (методы GET, POST, перенаправления и cookies). Схема протокола имеет следующий вид:

С учетом требований, описанных в спецификации WS-Federation Passive Requestor Profile, протоколом поддерживаются следующие форматы маркеров безопасности:

Протокол SAML

SAML (англ. security assertion markup language — язык разметки декларации безопасности) — язык разметки, основанный на языке XML. Открытый стандарт обмена данными аутентификации и авторизации между участниками, в частности, между поставщиком учётных записей (англ. identity provider) и поставщиком сервиса (англ. service provider). SAML — продукт OASIS, разработанный Техническим комитетом безопасности сервиcов. SAML создан в 2001 году; последнее значимое обновление SAML было опубликовано в 2005 году, но расширения протокола постоянно выпускались через дополнительные, опциональные стандарты.

Одной из важных проблем, которую пытается решить SAML, является обеспечение сквозной аутентификации при работе через Web-браузер. Использование SAML в качестве технологии единого входа на уровне сети (intranet) распространено (например, с использованием cookies), но расширение за пределы частной сети (intranet) было проблематично и привело к созданию несовместимых запатентованных технологий (другой, более современный подход обеспечения SSO — это протокол OpenID)

Протокол OpenID

OpenID — открытый стандарт децентрализованной системы аутентификации, предоставляющей пользователю возможность создать единую учётную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов, используя услуги третьих лиц.

Аутентификация посредством OpenID [FH07] обеспечивает возможность подтвердить, что пользователь обладает идентификатором без запроса доверенной стороной у пользователя его идентификационных данных, таких как пароль или адрес электронной почты. OpenID – децентрализованный протокол, пользователь может выбрать идентификатор какого провайдера OpenID предоставить. Для поддержки данного протокола требуется только JavaScript или современный веб-браузер. OpenID использует только стандарты HTTPS, то есть не требует никаких специальных возможностей клиентского программного обеспечения. Основными элементами процесса аутентификации являются:

Идентификатор OpenID – это строка, которая является уникальной для каждого пользователя. Один идентификатор не может принадлежать более чем одному пользователю. Различают следующие два вида идентификаторов:

Клиент OpenID (ЦП) – онлайн – ресурс (чаще всего веб-сайт, но им также может быть файл, изображение или любой ресурс, к которому необходимо контролировать доступ), который использует OpenID для идентификации обращающихся к нему пользователя.

Провайдер OpenID (ЦИ) – сайт, на котором пользователи могут получить идентификатор OpenID. Данный сайт может в будущем авторизовывать и аутентифицировать пользователей, обращающихся к Целевому Приложению. Провайдер OpenID также предоставляет веб-интерфейс для управления выданными идентификаторами.

Схема протокола выглядит следующим образом:

Протокол OAuth

Схема протокола имеет следующий вид:

Протокол OAuth является широко распространенным, благодаря его использованию сервисами поисковых систем, почтовыми сервисами, а также в социальных сетях.

Источник

SSO на микросервисной архитектуре. Используем Keycloak. Часть №1

В любой крупной компании, и X5 Retail Group не исключение, по мере развития возрастает количество проектов, где требуется авторизация пользователей. С течением времени требуется бесшовный переход пользователей из одного приложения в другой и тогда возникает необходимость использования единого сервера Single-Sing-On (SSO). Но как быть, когда такие идентификационные провайдеры как AD или иные, не обладающие дополнительными атрибутами, уже используются в различных проектах. На помощь придет класс систем под названием «идентификационные брокеры». Наиболее функциональными являются его представители, такие как Keycloak, Gravitee Access management и пр. Чаще всего сценарии использования могут быть различны: машинное взаимодействие, участие пользователей и пр. Решение должно поддерживать гибкий и масштабируемый функционал, способный объединить все требования в одном, и такие решением в нашей компании сейчас является индикационный брокер – Keycloak.

Keycloak – это продукт с открытым исходным кодом, предназначенный для идентификации и контроля доступа и поддерживаемый компанией RedHat. Он является основой для продуктов компании использующих SSO – RH-SSO.

Основные понятия

Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:

Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).

Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)

Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).

Идентификационный брокер Keycloak

Keycloak — это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.

Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.

Базовый функционал, поддерживаемый в Keycloak:

Идентификационные провайдеры уровня предприятия (On-Premise)

Возможность аутентификации пользователей через User Federation сервисы.

Также может быть использована сквозная аутентификация — если пользователи проходят аутентификацию на рабочих станциях с Kerberos (LDAP или AD), то они могут быть автоматически аутентифицированы на Keycloak без необходимости снова указывать свое имя пользователя и пароль.

Для аутентификации и дальнейшей авторизации пользователей возможно использование реляционной СУБД, что наиболее применимо для сред разработки, так как не влечет длительных настроек и интеграций на ранних стадиях проектов. По умолчанию в Keycloak используется встроенная СУБД для хранения настроек и данных о пользователях.

Список поддерживаемых СУБД обширен и включает в себя: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и другие. Наиболее протестированными на данный момент являются Oracle 12C Release1 RAC и Galera 3.12 cluster для MariaDB 10.1.19.

Идентификационные провайдеры — social login

Возможно использование логина из социальных сетей. Для активации возможности аутентифицировать пользователей используется консоль администратора Keycloack. Изменений в коде приложений не требуется и данный функционал доступен «из коробки» и может быть активирован в любой стадии реализации проекта.

Для аутентификации пользователей возможно использование OpenID/SAML Identity провайдеров.

Типовые сценарии авторизации с использование OAuth2 в Keycloak

Authorization Code Flow — используется с серверными приложениями (server-side applications). Один из наиболее распространенных типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, в которых исходный код приложения и даные клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection). Приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), таким как веб-браузер — получать коды авторизации API перенаправляемые через пользовательский агент.

Implicit Flow — используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).

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

Implicit Flow не поддерживает токены обновления токена доступа (refresh tokens).
Client Credentials Grant Flow — используются при доступе приложения к API. Этот тип разрешения на авторизацию обычно используется для взаимодействий «сервер-сервер», которые должны выполняться в фоновом режиме без немедленного взаимодействия с пользователем. Поток предоставления учетных данных клиента позволяет веб-службе (конфиденциальному клиенту) использовать собственные учетные данные вместо олицетворения пользователя для проверки подлинности при вызове другой веб-службы. Для более высокого уровня безопасности возможно вызывающей службе использовать сертификат (вместо общего секрета) в качестве учетных данных.

JWT токен и его преимущества

JWT (JSON Web Token) — открытый стандарт (https://tools.ietf.org/html/rfc7519), который определяет компактный и автономный способ для защищенной передачи информации между сторонами в виде JSON-объекта.

Согласно стандарту, токен состоит из трех частей в base-64 формате, разделенных точками. Первая часть называется заголовком (header), в которой содержится тип токена и название хэш-алгоритма для получения цифровой подписи. Вторая часть хранит основную информацию (пользователь, атрибуты и т.д.). Третья часть – цифровая подпись.

Refresh-токен — это токен, позволяющий клиентам запрашивать новые access-токены по истечении их времени жизни. Данные токены обычно выдаются на длительный срок.

Основные преимущества применения в микросервисной архитектуре:

JWT токен — состав

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

Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.

Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.

< "alg": "HS256", "typ": "JWT">
Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо). Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»

< "email": "example@x5.ru" >
Ключи в payload могут быть произвольными. Тем не менее, есть несколько зарезервированных:

Берутся закодированные в base64: заголовок и payload, они объединяются в строку через точку. Затем эта строка и секретный ключ поступает на вход алгоритма шифрования, указанного в заголовке (ключ «alg»). Ключом может быть любая строка. Более длинные строки будут наиболее предпочтительнее, поскольку потребуется больше времени на подбор.

Построение архитектуры отказоустойчивого кластера Keycloak

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

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

Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.

Самый простой пример отказоустойчивой инсталяции.

Какие преимущества дает использование единого кластера:

На что стоит обратить внимание при планировании кластера

Keycloak использует систему управления СУБД для сохранения: realms, clients, users и пр.
Поддерживается большой спектр СУБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak поставляется с собственной встроенной реляционной базой данных. Рекомендуется использование для ненагруженных сред – такие как среды разработки.

Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных и оба узла кластера баз данных синхронно реплицируются между ЦОД.

Распределенный кеш (Infinspan)

Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:

Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.

Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.

Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.

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

User sessions — используются для сохранения данных о сеансах пользователя, которые действительны в течение сеанса браузера пользователя. Кэш должен обрабатывать HTTP-запросы от конечного пользователя и приложения.

Brute force protection — используется для отслеживания данных о неудачных входах.

Балансировка нагрузки

Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.

Сервера приложений

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

На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.

Источник