Вход в личный кабинет Основные понятия
Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:
How does sso work?
Authentication with SSO relies on a trust relationship between domains (websites). With single sign-on, this is what happens when you try to log in to an app or website:
Jwt токен — состав
Заголовок
— по умолчанию, заголовок содержит только тип токена и алгоритм, используемый для шифрования.
Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.
Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.
{ “alg”: “HS256”, “typ”: “JWT”}Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо).
Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»
Saml sso flow
The diagram below illustrates the single sign-on flow for service provider-initiated SSO, i.e. when an application triggers SSO.
Sso strategy
SAML is an XML-based open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.
Балансировка нагрузки
Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.
Идентификационный брокер keycloak
Keycloak
— это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.
Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.
Базовый функционал, поддерживаемый в Keycloak:
Построение архитектуры отказоустойчивого кластера keycloak
При использовании единого кластера для всех проектов возникают повышенные требования к решению для SSO. Когда количество проектов невелико эти требования не так ощутимы для всех проектов, однако с увеличением количества пользователей и интеграций повышаются требования к доступности и производительности.
Повышение рисков отказа единого SSO повышает требования к архитектуре решения и используемых методов резервирования компонентов и приводит к очень жесткому SLA. В связи с этим чаще при разработке или ранних стадиях внедрения решений проекты имеют собственную не отказоустойчивую инфраструктуру.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.
Самый простой пример отказоустойчивой инсталяции.
Какие преимущества дает использование единого кластера:
- Высокая доступность и производительность.
- Поддержка режимов работы: Active/Active, Active/Passive.
- Возможность динамического масштабирования — при использовании контейнерной виртуализации.
- Возможность централизованного управления и мониторинга.
- Единый подход для идентификации/аутентификации/авторизации пользователей в проектах.
- Более прозрачное взаимодействие между различными проектами без участия пользователей.
- Возможность переиспользования JWT токена в различных проектах.
- Единая точка доверия.
- Более быстрый запуск проектов с использованием микросервисов/контейнерной виртуализации (не требуется поднятие и настройка дополнительных компонентов).
- Возможно приобретение коммерческой поддержки от вендора.
Прозрачная авторизация на rds с помощью sso (single sign-on) | windows для системных администраторов
Single Sign-On (SSO — технология единого входа) это технология, позволяющая уже аутентифицированному (вошедшему в систему) пользователю получать доступ к другим сервисам без повторной аутентификации. Применительно к технологии терминальных серверов Remote Desktop Services, SSO позволяет избавить пользователя, выполнившего вход на доменном компьютере, от многократного ввода имени и пароля своей учетной записи в окне RDP клиента при подключении к RDS серверам или запуске опубликованных приложений RemoteApp.
В этой статье мы опишем особенности настройки прозрачной авторизации (Single Sign-On) пользователей на серверах RDS под управлением Windows Server 2022 и 2022 R2.
Требования к окружению:
Процедура настройки Single Sign-On состоит из следующих этапов:
- Необходимо выпустить и назначить SSL сертификат на серверах RD Gateway, RD Web и RD Connection Broker;
- Включить Web SSO на сервере RDWeb;
- Настроить групповую политику делегирования учетных данных;
- Через GPO добавить отпечаток сертификата в доверенные издатели .rdp.
Итак, в первую очередь нужно выпустить и назначить SSL сертификат. В EKU (Enhanced Key Usage) сертификата должно обязательно присутствовать идентификатор Server Authentication. Мы опускаем процедуру получения сертификата, т.к. это она выходит за рамки статьи (можно сгенерировать самоподписанный SSL сертификат, но его придется добавлять в доверенные на всех клиентах через GPO).
SSL сертификат привязывается в свойствах RDS Deployment в подразделе Certificates.
Далее на всех серверах c ролью Web Access для каталога IIS RDWeb нужно включать “Windows Authentication” и отключить анонимную проверку подлинности (Anonymous Authentication).
После сохранения изменений, IIS нужно перезапустить:
iisreset /noforce
Если используется шлюз RD Gateway, убедитесь, что он не используется для подключения внутренних клиентов (должна стоять галка Bypass RD Gateway server for local address).
Следующий этап – настройка политики делегирования учетных данных. Создайте новую доменную GPO и привяжите ее к OU с пользователями (компьютерами), которым нужно разрешить SSO доступ на RDS сервера. Если вы хотите разрешить SSO для всех пользователей домена, допустимо редактировать Default Domain Policy.
Эта политика находится в разделе GPO Computer Configuration -> Administrative Templates -> System -> Credential Delegation -> Allow delegation defaults credential (Конфигурация компьютера -> Административные шаблоны -> Передача учетных данных -> Разрешить передачу учетных данных, установленных по-умолчанию). Политика разрешает определенным серверам доступ к учетным данным пользователей Windows.
Далее, чтобы избежать появления окна с предупреждением о надежности издателя удаленного приложения, нужно с помощью GPO на клиентских компьютерах добавить адрес сервера с ролью Connection Broker в доверенную зону с помощью политики «Список назначений зоны безопасности для веб-сайтов» (по аналогии со статьей Как убрать предупреждение системы безопасности при открытии файла в Windows):
User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page-> Site to Zone assignment list (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность)
Укажите FQDN имя сервера RDCB и зону 2 (Trusted sites).
Далее нужно включить политику Logon options (Параметры входа) в разделе User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security -> Trusted Sites Zone (Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность -> Зона надежных сайтов) и в выпадающем списке выбрать ‘Automatic logon with current username and password‘ (Автоматический вход в сеть с текущим именем пользователя и паролем).
После обновления политик на клиенте, при попытке запустить RemoteApp приложение, запрос пароля не появится, но появится окно с предупреждением о доверии к издателю данной программы RemoteApp:
Do you trust the publisher of this RemoteApp program?
Чтобы это сообщение не выводилось каждый раз при подключении пользователя, вам нужно получить отпечаток SSL сертификата (certificate thumbprint) RD Connection Broker и добавить его в список доверенных издателей rdp. Для этого на сервере RDS Connection Broker выполните команду PowerShell:
Get-Childitem CERT:LocalMachineMy
Скопируйте значение отпечатка сертификата и добавьте его в список отпечатков политики Specify SHA1 thumbprints of certificates representing RDP publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Administrative Templates -> Windows Components -> Windows Desktop Services -> Remote Desktop Connection Client (Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу).
На этом настройка SSO закончена, и после применения политик, пользователь должен подключатся к ферме RDS по протоколу RDP без повторного ввода пароля.
Теперь при запуске клиента mstsc.exe (Remote Desktop Connection), если вы укажете имя RDS сервера, в поле UserName автоматически подставится имя пользователя в формате ([email protected]).
Your Windows logon credentials will be used to connect.
Чтобы использовать RD Gateway с SSO нужно для пользователей включить политику Set RD Gateway Authentication Method (User Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> RD Gateway) и установить ее значение на Use Locally Logged-On Credentials.
Для использования Web SSO на RD Web Access, обратите внимание, что рекомендуется использовать Internet Explorer с включенным Active X компонентом MsRdpClientShell (Microsoft Remote Desktop Services Web Access Control).
Распределенный кеш (infinspan)
Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:
Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.
Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.
Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.
Work — используется только для отправки сообщений о недействительности между узлами кластера и центрами обработки данных.
Реализация sso через saml с примером
Введение
Доброго времени суток, дорогой читатель. Я уже давно хотел написать статью на хабре и вот наконец-то этот момент настал. Из последних тем, которыми я занимался и о которых мне есть что рассказать — это была реализация SSO для одного сервиса. Хочу здесь сразу уточнить, что в принципе SSO через Facebook и Google уже было в сервисе до моего прихода. Моей же задачей было реализовать его через протокол SAML.
SSO (Single Sign-On), — технология единого входа пользователей, благодаря которой владея одной лишь учетной записью пользователь может посещать множество различных сервисов.
SAML — это популярный XML-протокол для реализации SSO. Как правило большие организации (enterprise) используют именно его, как проверенный и надежный вариант.
В нашем сервисе появление этой фичи как раз и было обусловлено частыми запросами enterprise заказчиков на его реализацию. Такого рода заказчики централизованно ведут актуальную базу пользователей, вводят свои политики безопасности и т.п. Соответственно и доступ к контенту в сервисе становится более безопасным и контролируемым, чего в конце концов они и хотят.
Технические детали
На момент написания статьи, последняя версия стандарта — SAML 2.0. Базируется стандарт на XML, а значит и все требования стандартов w3c к XML так же применимы и к нему, не забывайте про это. Так, например в момент реализации, я словил одну ошибку. В момент создания AuthnRequest я генерировал уникальный строковый идентификатор для атрибута ID, так вот по требованиям он не должен начинаться с цифры, а у меня периодически так было.
В аутентификации через SAML SSO участвует три стороны:
Сама схема взаимодействия представлена на рисунке ниже
Из нее получается два основных кейса взаимодействия, причем один содержит в себе другой.
Вариант 1. Пользователь обращается к сервису. Сервис формирует сообщение AuthnRequest, кладет в параметр SAMLRequest и делает редирект через браузер к провайдеру на Login URL, где происходит аутентификация, затем провайдер формирует сообщение Response, кладет его в параметр SamlResponse и редиректит обратно в сервис на ACS URL.
Вариант 2. Пользователь уже аутентифицирован и находится в личном кабинете провайдера, откуда он может перейти в сервис, кликая по его ярлыку. В данной ситуации провайдер сразу формирует сообщение Response, кладет его в параметр SamlResponse и направляет в сервис на ACS URL.
ACS URL (Assertion Consumer Service URL) — урл на стороне нашего приложения, который принимает запросы с параметром SamlResponse, обрабатывает его (выдергивает сообщение Response, проверяет подпись по сертификату, различные правила) и если все хорошо, то создает рабочую сессию пользователя в приложении.
IdP Login URL — урл на стороне провайдера, который принимает запросы с параметром SAMLRequest и так же выполняет должную валидацию этого параметра, и если все хорошо, то отправляет на форму аутентификации.
В качестве IdP провайдeра может выступать один из онлайн-сервисов, таких как OneLogin, LastPass, Okta и другие. Также можно развернуть свой IdP с помощью Shibboleth или поднять AD.
Настройки
Все параметры для этого взаимодействия должны настраиваться и храниться на обеих сторонах (IdP, SP), то есть должны быть выстроены доверительные отношения.
SP должен хранить у себя сертификат, который выдаст IdP, а также Saml Login URL, на который будет отправлять SAMLRequest.
IdP обязательно должен хранить у себя для размещаемого приложения ACS URL…
… должен сформировать сертификат, выбрать алгоритм шифрования, предоставить Saml Login URL для сервиса…
… должен настроить (если необходимо) атрибуты пользователя или еще какие-то кастомные поля для конкретного сервиса. Сервис с провайдером должны также договориться о формате Subject NameID. Это по сути идентификатор пользователя, информация о котором будет передана в сообщениях. В нашем случае это email.
Помимо ручной настройки, SP и IdP должны уметь генерировать файл метаданных, содержащий все необходимые параметры для “коллеги”, чтобы тот мог и загрузить и выставить настройки сам. У нас такой задачи не было.
В дополнение еще скажу, что помимо SSO, провайдеры опционально предоставляют еще и услугу SLO (Single Logout) — механизм, который предполагает выход сразу из всех сервисов одновременно. Возможны также две точки входа:
Для этого надо поддержать на стороне сервиса обработку запросов SP SLO URL и отправку запросов к IdP SLO URL. Такой задачи у меня также не было.
Исследования
И так, задача поставлена, с теорией ознакомился, пора и делать начать. Первым делом ознакомился со списком имеющихся библиотек. Backend нашего сервиса написан на Java, искал библиотеки именно для него. Наиболее полный список продуктов, связанных с SAML можно увидеть тут. Выбрал для себя наиболее очевидные решения: Okta SAML Toolkit for Java, SpringSecurity SAML, OIOSAML 2.0 Toolkit, lastpass/saml-sdk-java, OneLogin 2.0, OneLogin 1.1.2, OpenSAML 2.0. Далее нужно было определить критерии, по которым будет выбрано то или иное решение. Так была составлена следующая таблица.
Если честно, исходный код предложенных решений просто ужаснул — известные провайдеры решили написать свои высокоуровневые прикладные библиотеки (получилось не очень), большая часть (слава богу) решений была основана на низкоуровневой библиотеке работы с SAML OpenSaml 2.0. Учитывая, что все эти библиотеки так или иначе пришлось бы править затачивая под потребности нашей логики и встраивать в наш основной код со всеми юнит-тестами было решено также использовать уже имеющийся базис в виде OpenSaml 2.0 и на нем писать нашу высокоуровневую логику. Возможно, если бы у нас был Spring, я бы стал использовать SpringSecurity SAML, но его у нас нет.
Вообще, все свои мысли и варианты решения я изложил в нашем же сервисе для дальнейшего обсуждения командой, скрин можно глянуть ниже или перейти на “живую” доску, участие в наполнении которой принимал не только я.
Итого, решение выбрано, поведение определено.
Реализация
В качестве IdP для тестирования я выбрал, как можно увидеть по скринам выше, OneLogin. Он предоставляет бесплатный девeлоперский аккаунт, с ним проще всего было настроить тестовое приложение, а также он содержит набор утилит для работы с SAML, которые смогут облегчить Вам работу. Если не надо никакого полноценного конфигурируемого IdP, то можно использовать простую эту утилиту или ее аналог от Okta. Ими я тоже пользовался.
Сначала я написал свое тестовое локальное приложение чтобы обкатать в принципе эту технологию, его исходники я Вам и продемонстрирую. Затем уже перенес это решение на промышленную кодобазу. Логика приложения простая и применимая для любого сервиса. Приложение предлагает пользователю ввести email, если для этого домена не настроено SSO SAML, то приложение просит ввести внутренний пароль юзера (в примере ругается, что юзер не может SSO). Если же настроено, то смотрим на какой IdP настроен данный домен, формируем сообщение и перенаправляем запрос туда. После успешной аутентификации получаем сформированное сообщение на наш ACS URL от IdP, из сообщения берем email, берем сертификат для данного домена и проводим валидацию сообщения. В случае успешной проверки берем атрибуты из сообщения FirstName, LastName. Если пользователь уже существует меняем ему значения этих атрибутов в нашем сервисе. Если пользователя еще нет, то создаем его.
Это так называемый Just-in-Time Provisioning. Эта самая простая реализация провижининга (синхронизация) пользователей, которую можно сделать. Минусом такой синхронизации можно назвать отсрочку выполнения до следующего входа пользователя. Плюс невозможность удаления пользователя на стороне сервиса при удалении юзера из IdP. Чтобы полноценно запустить провижининг в сервисе необходимо реализовать стандарт SCIM, но этого я еще не делал — возможно это будет следующая история.
Надеюсь, эта статья была полезна для Вас.
Сервера приложений
Используются для контроля взаимодействия компонентов между собой и могут быть виртуализированы или контейнерезированы с применением имеющихся средств автоматизации и динамического масштабирования средств автоматизации инфраструктуры. Наиболее распространенные сценарии развертывания в OpenShift, Kubernates, Rancher.
На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.
Системы единого входа (sso)
Cистемы единого входа (SSO, Single Sign-On) — это отдельный тип продуктов или встраиваемая технология, позволяющие не прибегать к повторной аутентификации пользователя при его переходе по различным разделам и сервисам одного портала, таким как форум, блог и другие, или при работе с несколькими приложениями. Другими словами, пользователь проходит процедуру аутентификации в одном месте, после чего получает доступ ко всем связанным разделам, и ему не приходится вводить свои учетные данные в нескольких формах.
В отличие от стандартных методов аутентификации при попытках пользователя получить доступ к сервису, запрос аутентификационных данных направляется не к пользователю, а в SSO-приложение.
Существуют несколько вариантов применения технологии Single Sign-On, а именно:
- Клиентский;
- Серверный;
- Комбинированный;
- Web SSO.
При этом при использовании технологии Single Sign-On могут применяться следующие способы реализации:
- Маркеры доступа.
- Аутентификация на основе Kerberos.
- Смарт-карты или USB-токены.
- Технология PKI и применение цифровых сертификатов.
- Методы автоматической подстановки паролей.
Указанные способы реализации работают на основе протоколов:
- WS-Security. Аутентификация по данному протоколу подразумевает использование на стороне клиента только браузера.
- OpenID. Позволяет использовать учетную запись на различных интернет-ресурсах, которые не связаны между собой. Такая возможность достигается за счет использования услуг третьих лиц.
- Oauth. Позволяет предоставлять собственные ресурсы, не раскрывая при этом свои данные идентификации. Таким образом, клиент получает доступ к ресурсам от имени учетной записи владельца данных.
- SAML. Данный протокол позволяет выполнять аутентификацию на уровне сети, используя только браузер пользователя.
- Kerberos.
К преимуществам технологии единого входа относятся:
- Сокращение времени, необходимого для аутентификации пользователя. Пользователю больше не требуется постоянно вводить пароли при переходе с одного сервиса на другой.
- Сокращение количества паролей, которые необходимо хранить в памяти. При использовании SSO достаточно запомнить один пароль, который будет подходить для любого приложения, из одного пула.
- Снижение количества запросов аутентификации. В момент прохождения процедуры аутентификации вырастает нагрузка на сеть за счет отправки пакетов с аутентификационной информацией. При использовании технологии SSO количество таких пакетов значительно сократится.
- Контроль информации, связанной с управлением доступом. Возможность изменения прав доступа к различным сервисам в единой консоли.
- В связи с тем, что использование технологии единого входа достаточно сильно упрощает работу пользователей сервиса, можно говорить о сокращении расходов владельца информационной системы за счет уменьшения количества обращений пользователей.
- Упрощение процесса регистрации событий безопасности, связанных с процедурой идентификации и аутентификации — все события находятся в одном месте.
Однако у технологии SSO имеется и ряд недостатков:
- В зависимости от количества систем, которые необходимо подключить к точке единого входа, процесс реализации может быть затянутым и дорогостоящим. При внедрении стоит учитывать необходимость использования специальных агентов, которые могут быть несовместимы с используемым программным обеспечением или устройствами.
- В случае компрометации учетной записи пользователя может быть получен несанкционированный доступ ко всем ресурсам, которые подключены к единой точке входа.
Типовые сценарии авторизации с использование oauth2 в keycloak
Authorization Code Flow