SSO (версия для системного администратора)

Описание ситуации

Пользователи не хотят увеличивать количество учётных записей. Им хочется использовать свою корпоративную почту как аккаунт для всех платформ. В этом случае необходимо использовать технологию SSO.

Все об SSO

SSO (Single Sign-On) — это система аутентификации, позволяющая пользователю входить в несколько приложений или сервисов с использованием единственных учетных данных (обычно логина и пароля). Это упрощает процесс входа, сокращает количество паролей, которые пользователю нужно запоминать, и повышает уровень безопасности, уменьшая риски, связанные с утечкой данных.

Функционирование SSO

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

Центральная служба SSO

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

Токен для SSO

Токен SSO представляет собой электронный документ с данными, идентифицирующими пользователя, например, логин или e-mail. При запросе пользователя на доступ, программа и сервис SSO обмениваются данным токеном для подтверждения пользователя.

Механизм SSO:

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

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

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

Виды протоколов SSO

SSO использует различные протоколы и стандарты для проверки и аутентификации учётных данных пользователей. Ниже будут прописаны основные из них:

1. SAML - протокол обмена информацией об аутентификации с SSO сервисом. Основан на XML, обеспечивает высокую безопасность, так как приложения не сохраняют учетные данные пользователей.
2. OAuth - открытый стандарт, позволяющий приложениям обращаться к данным пользователя без передачи пароля. Работает через API, устанавливая доверительные отношения между приложениями.
3. OIDC - подход, где одни учетные данные дают доступ к разным сайтам. Поставщик услуг осуществляет проверку подлинности, а приложения запрашивают дополнительные данные для проверки пользователя.
4. Kerberos - cистема аутентификации на основе "билетов", защищающая личность участников сети с помощью криптографии.

Команда разработчиком SmartPlayer использует для настройки протокол SAML

Настройка серверного приложения

Подготовка

1.Подключиться по ssh (или с помощью других инструментов) на удаленный сервер, где установлено серверное приложение SmartPlayer. Используем логин и пароль от сервера.

2. Перейти в папку, где установлена платформа SmartPlayer.

По умолчанию это путь: “/home/smartplayer/smartplayer/“ и открыть на редактирование файл .env. Данный файл является скрытым. Далее для его изменения открываем любым текстовым редактором, по умолчанию: nano /home/smartplayer/smartplayer/.env

3. Производим настройку в конфигурационном файле серверного приложения. Выбираем конфигурацию с протоколом SAML:

Пример команд для настройки SSO через SAML

Текст подписи

Название параметра	Допустимые значения	Описание
SSO_SAML_ENABLED	0 - выключена интеграция. 1 - включена интеграция	По умолчанию отключена. Чтобы включить используйте значение 1
SSO_SAML_ENTITY_ID	Любое строковое значение.	Служит для определения SAML клиента на стороне сервиса аутентификации. Это значение необходимо предварительно согласовать
SSO_SAML_Login_URL	URL сервиса аутентификации	Выдается сервисом аутентификации
SSO_SAML_CERTIFICATE_PATH	Путь до публичного сертификата от сервисом аутентификации	Сертификат выдается сервисом аутентификации
SSO_SAML_COMPANY_ID	Число указанное в профиле компании	Сертификат выдается сервисом аутентификации
LOCAL_SSL_KEY_PATH	Путь до приватного ключа сертификата	Сертификат выдается сервисом аутентификации.
LOCAL_SSL-CERT_PATH	Путь до публичного ключа сертификата	Сертификат выдается сервисом аутентификации.

Работа по протоколу SAML осуществляется только по https, поэтому так же необходимо проверить наличие ssl сертификатов и переменных: LOCAL_SSL_KEY_PATH и LOCAL_SSL_CERT_PATH.

Пример настроенного SSO

4. Сохранить изменения в конфигурационном файле.
5. Перезапустить полностью контейнеры Docker. Это необходимо в связи с внесёнными изменениями в .env файл.

• Перейти в папку, где находится файл *.yml. По умолчанию путь:
  

“/home/smartplayer/smartplayer/“

• Остановить контейнеры Docker docker-compose down
• Запустить контейнеры Docker docker-compose up -d

6. Подождать от 2 до 5 минут, для запуска платформы и можно заходить в личный кабинет. Вход осуществляется по URL личного кабинета.

Принцип действия

Производимые действия

Со стороны пользователя	Со стороны сервера
Пользователь заходит на страницу аутентификации и нажимает кнопку зайти по SSO	Фронтэнд Smartplayer отправляет к бэкенду запрос на редирект
Пользователя переносит на страницу аутентификации его компании	Бэкенд SmartPlayer формирует запрос на ADFS сервер клиента и редиректит пользователя на страницу аутентификации компании с помощью протокола SAML
Пользователь заполняет личные данные (логин и пароль) на странице аутентификации его компании	Сервер клиента собирает данные и параметры для ответа
Пользователя переносит в личный кабинет SmartPlayer	Сервер клиента снова с помощью SAML отправляет ответ для сервера SmartPlayer. Сервер SmartPlayer расшифровывает полученные данные и логинит пользователя.
Пользователь может использовать весь функционал платформы SmartPlayer в зависимости от своей роли: пользователь или администратор. Это настраивается на стороне клиента в ADFS сервере	После входа сервер SmartPlayer сохраняет данные и параметры о пользователе в своей базе данных

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

Соотношение прав

g_smartplayer_admins: 'adminBrand', по факту g_smartplayer_admins = 'adminBrand'= правам администратора
g_smartplayer_manager: 'userBrand', по факту g_smartplayer_manager = 'userBrand' = правам пользователя

Выявленные проблемы при настройке

• Ситуация: неправильно настроены claim rules.
  

Решение: Claim rules обязательно должны быть настроены на одном языке. В нашем случае на сервере SmartPlayer claim rules были прописаны на русском языке, а у клиента не английском. На нашей стороне было прописано "Адрес электронной почты", а у клиента "Е-mail". После того, как заказчик переписал их на своём ADFS сервере на русском, проблема решилась.

• Ситуация: некорректная отправка сертификатов.
  

Решение: Системные администраторы со стороны заказчика отправили сертификат в виде текста, что оказалось некорректным и неудобным в использовании. После отправки сертификата в виде файла, ситуация была решена.

Итоговый результат

В результате всех произведённых выше действий системный администратор пользователя "поднимет" систему SSO на своём сервере. Это даст возможность пользователю не создавать отдельную учётную запись. Таким образом получит боле простой, комфортный и безопасный доступ к функционалу SmartPlayer.