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 использует различные протоколы и стандарты для проверки и аутентификации учётных данных пользователей.
Ниже будут прописаны основные из них:
- SAML - протокол обмена информацией об аутентификации с SSO сервисом. Основан на XML, обеспечивает высокую безопасность, так как приложения не сохраняют учетные данные пользователей.
- OAuth - открытый стандарт, позволяющий приложениям обращаться к данным пользователя без передачи пароля. Работает через API, устанавливая доверительные отношения между приложениями.
- OIDC - подход, где одни учетные данные дают доступ к разным сайтам. Поставщик услуг осуществляет проверку подлинности, а приложения запрашивают дополнительные данные для проверки пользователя.
- Kerberos - cистема аутентификации на основе "билетов", защищающая личность участников сети с помощью криптографии.
Настройка серверного приложения
Подготовка
1.Подключиться по ssh (или с помощью других инструментов) на удаленный сервер, где установлено серверное приложение SmartPlayer. Используем логин и пароль от сервера.
2. Перейти в папку, где установлена платформа SmartPlayer.
По умолчанию это путь: “/home/smartplayer/smartplayer/“ и открыть на редактирование файл .env. Данный файл является скрытым. Далее для его изменения открываем любым текстовым редактором, по умолчанию:
nano /home/smartplayer/smartplayer/.env
3. Производим настройку в конфигурационном файле серверного приложения. Выбираем конфигурацию с протоколом 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 | Путь до публичного ключа сертификата | Сертификат выдается сервисом аутентификации. |
LOCAL_SSL_KEY_PATH и LOCAL_SSL_CERT_PATH.
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.
