SSO (версия для системного администратора): различия между версиями

Материал из SmartPlayer
Нет описания правки
 
(не показаны 22 промежуточные версии этого же участника)
Строка 1: Строка 1:
=='''Принцип действия'''==
<languages/>
=== '''Настройка серверного приложения''' ===
<translate>
<!--T:1-->
== '''Описание ситуации''' ==
Пользователи не хотят увеличивать количество учётных записей. Им хочется использовать свою корпоративную почту как аккаунт для всех платформ. В этом случае необходимо использовать технологию SSO.
</translate>
<translate>
<!--T:2-->
== '''Все об SSO''' ==
'''SSO (Single Sign-On)''' — это система аутентификации, позволяющая пользователю входить в несколько приложений или сервисов с использованием единственных учетных данных (обычно логина и пароля). Это упрощает процесс входа, сокращает количество паролей, которые пользователю нужно запоминать, и повышает уровень безопасности, уменьшая риски, связанные с утечкой данных.
=== '''Функционирование SSO''' ===
SSO создает соединение между программой и внешним сервис-поставщиком, иногда называемым идентификатором пользователя (IdP). Это связывание осуществляется через последовательность действий по аутентификации, подтверждению и связке между программой и центральной службой SSO. Это ключевые элементы системы SSO.<br>
=== '''Центральная служба SSO''' ===
Эта служба является главной для приложений при попытке пользователя войти в систему. Когда анонимный пользователь пытается получить доступ, программа направляет его к службе SSO. После аутентификации служба возвращает пользователя к запрашиваемой программе. Обычно это происходит на специализированном сервере политик SSO.<br>
=== '''Токен для SSO''' ===
Токен SSO представляет собой электронный документ с данными, идентифицирующими пользователя, например, логин или e-mail. При запросе пользователя на доступ, программа и сервис SSO обмениваются данным токеном для подтверждения пользователя.<br>
=== '''Механизм SSO:''' ===
Пользователь, обращаясь к программе, инициирует создание SSO-токена, который направляется для проверки в службу SSO.
Сервис определяет, проходил ли ранее процесс аутентификации для этого пользователя. Если процедура была успешной, служба подтверждает доступ для программы.<br><br>
Если у пользователя нет учетной записи, служба SSO направляет его к главной странице входа, предлагая ввести логин и пароль.
После проверки учетных данных служба отправляет положительный отклик программе.<br><br>
В противном случае появляется уведомление об ошибке, и пользователь должен попробовать снова. Несколько неудачных попыток могут привести к временной блокировке доступа к службе.
=== '''Виды протоколов SSO''' ===
SSO использует различные протоколы и стандарты для проверки и аутентификации учётных данных пользователей.
[[File:Виды протоколов.png|thumb|right| Основные виды защитных протоколов SSO|300px]]
Ниже будут прописаны основные из них:<br>
# SAML - протокол обмена информацией об аутентификации с SSO сервисом. Основан на XML, обеспечивает высокую безопасность, так как приложения не сохраняют учетные данные пользователей.
# OAuth - открытый стандарт, позволяющий приложениям обращаться к данным пользователя без передачи пароля. Работает через API, устанавливая доверительные отношения между приложениями.
# OIDC - подход, где одни учетные данные дают доступ к разным сайтам. Поставщик услуг осуществляет проверку подлинности, а приложения запрашивают дополнительные данные для проверки пользователя.
# Kerberos - cистема аутентификации на основе "билетов", защищающая личность участников сети с помощью криптографии.
{{Note|Команда разработчиком SmartPlayer использует для настройки протокол '''SAML'''|warn}}
</translate>
<translate>
<!--T:3-->
== '''Настройка серверного приложения''' ==
=== '''Предварительные действия''' ===
{{Note|Для начала работ необходимо чтобы системный администратор клиента настроил на своей стороне ADFS сервер|warn}}
Далее необходимо  провзаимодействовать с командой SmartPlayer. Это нужно для включения  функционала на бэкенде. А также добавиление его отображения во фронтентде на странице аутентификации.<br>
Для этого существует файл с конфигурациями который отвечает за включение кнопки SSO.<br>
Путь к нему: <code>/home/smartplayer/smartplayer/cms/cms/config.js</code>.<br>
В этом файле необходимо изменить параметр <code>showSSOButton</code> и выставить ему значение ''true''<br>
Также предварительно системный администратор со стороны клиента должен прислать нашей команде параметры для конфига:<br>
<code>SSO SAML certificate </code><br>
<code>SSO_SAML_LOGIN_URL</code><br>
Со стороны нашей команды также отправляется файл с метаданными.
</translate>
<translate>
 
=== '''Подготовка''' ===
1.Подключиться по ssh (или с помощью других инструментов) на удаленный сервер, где установлено серверное приложение SmartPlayer. Используем логин и пароль от сервера. <br><br>
1.Подключиться по ssh (или с помощью других инструментов) на удаленный сервер, где установлено серверное приложение SmartPlayer. Используем логин и пароль от сервера. <br><br>


<!--T:5-->
2. Перейти в папку, где установлена платформа SmartPlayer.<br>
2. Перейти в папку, где установлена платформа SmartPlayer.<br>


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


3. Производи настройку в конфигурационном файле серверного приложения. Выбираем  конфигурацию с протоколом SAML:
<!--T:7-->
3. Производим настройку в конфигурационном файле серверного приложения. Выбираем  конфигурацию с протоколом SAML:
[[File:Настройка SSO через SAML.png|thumb|right|Пример команд для настройки SSO через SAML|300px]]
{| class="wikitable sortable"
{| class="wikitable sortable"
|+ Текст подписи
|+ Текст подписи
Строка 14: Строка 65:
! '''Название параметра''' !! '''Допустимые значения''' !! '''Описание'''
! '''Название параметра''' !! '''Допустимые значения''' !! '''Описание'''
|-
|-
| SSO_SAML_ENABLED || 0 - выключена интеграция. 1 - включена интеграция. || По умолчанию отключена. Чтобы включить используйте значение 1
| SSO_SAML_ENABLED || 0 - выключена интеграция. 1 - включена интеграция || По умолчанию отключена. Чтобы включить используйте значение 1
|-
| SSO_SAML_ENTITY_ID || Любое строковое значение. || Служит для определения SAML клиента на стороне сервиса аутентификации. Это значение необходимо предварительно согласовать
|-
|-
| SSO_SAML_ENTITY_ID || Любое строковое значение. || Служит для определения SAML клиента на стороне сервиса аутентификации. Это значение необходимо предварительно согласовать.
| SSO_SAML_Login_URL || URL сервиса аутентификации || Выдается сервисом аутентификации
|-
|-
| SSO_SAML_LOGIN_URL || URL сервиса аутентификации. ||
| SSO_SAML_CERTIFICATE_PATH || Путь до публичного сертификата от сервисом аутентификации || Сертификат выдается сервисом аутентификации
Выдается сервисом аутентификации
|-
|-
| SSO_SAML_CERTIFICATE_PATH || Путь до публичного сертификата от сервисом аутентификации || Сертификат выдается сервисом аутентификации.
| SSO_SAML_COMPANY_ID || Число указанное в профиле компании || Сертификат выдается сервисом аутентификации
|-
| LOCAL_SSL_KEY_PATH || Путь до приватного ключа сертификата || Сертификат выдается сервисом аутентификации.
|-
| LOCAL_SSL-CERT_PATH || Путь до публичного ключа сертификата || Сертификат выдается сервисом аутентификации.
|}
|}
{{Note|Работа по протоколу '''SAML''' осуществляется только по ''https'', поэтому так же необходимо проверить наличие ''ssl'' сертификатов и переменных: <code>LOCAL_SSL_KEY_PATH и LOCAL_SSL_CERT_PATH.</code>|warn}}
{{Note|Работа по протоколу '''SAML''' осуществляется только по ''https'', поэтому так же необходимо проверить наличие ''ssl'' сертификатов и переменных: <code>LOCAL_SSL_KEY_PATH и LOCAL_SSL_CERT_PATH.</code>|warn}}
==== Пример ====
[[File:Пример настройки SSO.png|thumb|center| Пример настроенного SSO |700px]]
[[File:Пример настройки SSO.png|thumb|center| Пример настроенного SSO |700px]]
4. Сохранить изменения в конфигурационном файле.<br>
4. Сохранить изменения в конфигурационном файле.<br>
Строка 33: Строка 88:
* Запустить контейнеры Docker <code>docker-compose up -d</code>
* Запустить контейнеры Docker <code>docker-compose up -d</code>
6. Подождать от 2 до 5 минут, для запуска платформы и можно заходить в личный кабинет. Вход осуществляется по URL личного кабинета.
6. Подождать от 2 до 5 минут, для запуска платформы и можно заходить в личный кабинет. Вход осуществляется по URL личного кабинета.
== '''Выявленные проблемы в кейсах''' ==
</translate>
* Ситуация: неправильно настроены claim rules.<br>
<translate>
Решение: Claim rules обязательно должны быть настроены на одном языке. В нашем случае на сервере SmartPlayer claim rules были прописаны на русском языке, а у клиента не английском. После того, как заказчик переписал их на своём ADFS сервере на русском, проблема решилась.
<!--T:8-->
* Ситуация: некорректная отправка сертификатов. <br>
=='''Принцип действия'''==
Решение: Системные администраторы со стороны заказчика отправили сертификат в виде текста, что оказалось некорректным и неудобным в использовании. После отправки сертификата в виде файла, ситуация была решена.  
{| class="wikitable"
== '''Команды для интеграции с SSO SAML''' ==
|+ Производимые действия
[[File:Настройка SSO через SAML.png|thumb|Пример отображения "Чёрного" экрана в личном кабинете пользователя|700px]]
|-
! Со стороны пользователя  !! Со стороны сервера
|-
| Пользователь заходит на страницу аутентификации и нажимает кнопку зайти по SSO|| Фронтэнд Smartplayer отправляет к бэкенду запрос на редирект
|-
| Пользователя переносит на страницу аутентификации его компании || Бэкенд SmartPlayer формирует запрос на ADFS сервер клиента и редиректит пользователя на страницу аутентификации компании с помощью протокола SAML
|-
| Пользователь заполняет личные данные (логин и пароль) на странице аутентификации его компании || Сервер клиента собирает данные и параметры для ответа
|-
| Пользователя переносит в личный кабинет SmartPlayer || Сервер клиента снова с помощью SAML отправляет ответ для сервера SmartPlayer. Сервер SmartPlayer расшифровывает полученные данные и логинит пользователя.
|-
| Пользователь может использовать весь функционал платформы SmartPlayer в зависимости от своей роли: пользователь или администратор. Это настраивается на стороне клиента в ADFS сервере || После входа сервер SmartPlayer сохраняет данные и параметры о пользователе в своей базе данных
|}
{{Note|Возможно сделать на этапе аутентификации сделать автолог. В данном случае пользователь запросил обязательный вход при начале каждой сессии|warn}}
[[File:Запрос.png|thumb|Пример запроса от сервера|300px]]
=== '''Соотношение прав''' ===
<code>g_smartplayer_admins: 'adminBrand'</code>, по факту ''g_smartplayer_admins = 'adminBrand'= правам администратора''<br>
<code>g_smartplayer_manager: 'userBrand'</code>, по факту ''g_smartplayer_manager = 'userBrand' = правам пользователя''
</translate>
<translate>
<!--T:9-->
== '''Выявленные проблемы при настройке''' ==
* '''Ситуация:''' неправильно настроены claim rules.<br>
[[File:Claim rules .png|thumb|Пример разницы в заполнении "Claim Rules"|300px]]
'''Решение:''' Claim rules обязательно должны быть настроены на одном языке. В нашем случае на сервере SmartPlayer claim rules были прописаны на русском языке, а у клиента на английском. На нашей стороне было прописано "Адрес электронной почты", а у клиента "Е-mail". После того, как заказчик переписал их на своём ADFS сервере на русском, проблема решилась.
* '''Ситуация:''' некорректная отправка сертификатов. <br>
'''Решение:''' Системные администраторы со стороны заказчика отправили сертификат в виде текста, что оказалось некорректным и неудобным в использовании. После отправки сертификата в виде файла, ситуация была решена.
 
== '''Итоговый результат''' ==
В результате всех произведённых выше действий системный администратор пользователя "поднимет" систему SSO на своём сервере. Это даст возможность пользователю не создавать отдельную учётную запись. Таким образом получит боле простой, комфортный и безопасный доступ к функционалу SmartPlayer.
</translate>

Текущая версия от 08:58, 25 августа 2023

Другие языки:

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

Пользователи не хотят увеличивать количество учётных записей. Им хочется использовать свою корпоративную почту как аккаунт для всех платформ. В этом случае необходимо использовать технологию 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 использует различные протоколы и стандарты для проверки и аутентификации учётных данных пользователей.

Основные виды защитных протоколов SSO

Ниже будут прописаны основные из них:

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

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

Предварительные действия

Для начала работ необходимо чтобы системный администратор клиента настроил на своей стороне ADFS сервер

Далее необходимо провзаимодействовать с командой SmartPlayer. Это нужно для включения функционала на бэкенде. А также добавиление его отображения во фронтентде на странице аутентификации.
Для этого существует файл с конфигурациями который отвечает за включение кнопки SSO.
Путь к нему: /home/smartplayer/smartplayer/cms/cms/config.js.
В этом файле необходимо изменить параметр showSSOButton и выставить ему значение true
Также предварительно системный администратор со стороны клиента должен прислать нашей команде параметры для конфига:
SSO SAML certificate
SSO_SAML_LOGIN_URL
Со стороны нашей команды также отправляется файл с метаданными.

Подготовка

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"

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

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

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

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

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