SSO (версия для системного администратора)/en: различия между версиями
(Новая страница: «== '''Description of the situation''' == Users don't want to increase the number of accounts. They want to use their corporate email as an account for all platforms. In this case, the SSO technology is needed.») |
(Новая страница: «=== '''Preparation:''' === Connect via ssh (or using other tools) to the remote server where the SmartPlayer server application is installed. Use the server's login and password. <br><br>») |
||
| Строка 1: | Строка 1: | ||
== '''Description of the situation''' == | == '''Description of the situation''' == | ||
Users don't want to increase the number of accounts. They want to use their corporate email as an account for all platforms. In this case, the SSO technology is needed. | Users don't want to increase the number of accounts. They want to use their corporate email as an account for all platforms. In this case, the SSO technology is needed. | ||
== '''All about SSO:''' == | |||
== ''' | '''SSO (Single Sign-On)''' — is an authentication system that allows a user to log into multiple applications or services using a single set of credentials (usually a login and password). It simplifies the login process, reduces the number of passwords a user needs to remember, and enhances security by reducing risks associated with data breaches. | ||
'''SSO (Single Sign-On)''' — | === '''How SSO Works''' === | ||
=== ''' | SSO establishes a connection between an application and an external service provider, sometimes referred to as a user identifier (IdP). This linking is done through a series of authentication, verification, and binding actions between the application and the central SSO service. These are the key elements of the SSO system.<br> | ||
SSO | === '''Central SSO Service''' === | ||
=== ''' | This service is primary for applications when a user attempts to log in. When an anonymous user tries to gain access, the application directs them to the SSO service. After authentication, the service returns the user to the requested application. This typically takes place on a dedicated SSO policy server.<br> | ||
=== '''SSO Token''' === | |||
=== ''' | The SSO token is an electronic document containing data that identifies the user, such as a username or email. When a user requests access, the application and the SSO service exchange this token to validate the user.<br> | ||
=== '''SSO Mechanism''' === | |||
=== ''' | When a user accesses an application, they initiate the creation of an SSO token, which is sent to the SSO service for verification. The service determines if the authentication process has previously been completed for this user. If the procedure was successful, the service confirms access for the application.<br><br> | ||
If the user does not have an account, the SSO service redirects them to the main login page, prompting them to enter their username and password. | |||
After verifying the credentials, the service sends a positive response to the application.<br><br> | |||
Otherwise, an error notification appears, and the user is asked to try again. Multiple failed attempts may lead to temporary access suspension to the service. | |||
=== '''SSO Protocols''' === | |||
SSO employs various protocols and standards to verify and authenticate users' credentials. | |||
=== ''' | [[File:Виды протоколов.png|thumb|right| | ||
SSO | Main types of security protocols SSO|300px]] | ||
[[File:Виды протоколов.png|thumb|right| | The primary ones are outlined below:<br> | ||
# SAML - a protocol for exchanging authentication information with an SSO service. Based on XML, it ensures high security as applications do not store user credentials. | |||
# SAML - | # OAuth - an open standard allowing applications to access user data without transferring the password. It operates through API, establishing trust relationships between applications. | ||
# OAuth - | # OIDC - an approach where one set of credentials provides access to various sites. The service provider performs authentication, and applications request additional data to verify the user. | ||
# OIDC - | # Kerberos - an authentication system based on "tickets", protecting network participants' identities through cryptography. | ||
# Kerberos - | {{Note|The SmartPlayer development team uses the SAML protocol for configuration'''SAML'''|warn}} | ||
{{Note| | == '''Setting up the Server Application''' == | ||
=== '''Preliminary Steps''' === | |||
{{Note|Initially, the client's system administrator needs to set up the ADFS server on their end.|warn}} | |||
== ''' | Next, contact the SmartPlayer team so they can enable this feature on the backend and also add its display on the frontend authentication page.<br> | ||
=== ''' | Additionally, the client's system administrator should send our team the configuration parameters:<br> | ||
{{Note| | |||
<code>SSO SAML certificate </code><br> | <code>SSO SAML certificate </code><br> | ||
<code>SSO_SAML_LOGIN_URL</code><br> | <code>SSO_SAML_LOGIN_URL</code><br> | ||
From our team's side, a metadata file is also sent. | |||
=== '''Preparation:''' === | |||
Connect via ssh (or using other tools) to the remote server where the SmartPlayer server application is installed. Use the server's login and password. <br><br> | |||
=== ''' | |||
Navigate to the folder where the SmartPlayer platform is installed. | |||
<div lang="ru" dir="ltr" class="mw-content-ltr"> | <div lang="ru" dir="ltr" class="mw-content-ltr"> | ||
Версия от 16:54, 11 августа 2023
Description of the situation
Users don't want to increase the number of accounts. They want to use their corporate email as an account for all platforms. In this case, the SSO technology is needed.
All about SSO:
SSO (Single Sign-On) — is an authentication system that allows a user to log into multiple applications or services using a single set of credentials (usually a login and password). It simplifies the login process, reduces the number of passwords a user needs to remember, and enhances security by reducing risks associated with data breaches.
How SSO Works
SSO establishes a connection between an application and an external service provider, sometimes referred to as a user identifier (IdP). This linking is done through a series of authentication, verification, and binding actions between the application and the central SSO service. These are the key elements of the SSO system.
Central SSO Service
This service is primary for applications when a user attempts to log in. When an anonymous user tries to gain access, the application directs them to the SSO service. After authentication, the service returns the user to the requested application. This typically takes place on a dedicated SSO policy server.
SSO Token
The SSO token is an electronic document containing data that identifies the user, such as a username or email. When a user requests access, the application and the SSO service exchange this token to validate the user.
SSO Mechanism
When a user accesses an application, they initiate the creation of an SSO token, which is sent to the SSO service for verification. The service determines if the authentication process has previously been completed for this user. If the procedure was successful, the service confirms access for the application.
If the user does not have an account, the SSO service redirects them to the main login page, prompting them to enter their username and password.
After verifying the credentials, the service sends a positive response to the application.
Otherwise, an error notification appears, and the user is asked to try again. Multiple failed attempts may lead to temporary access suspension to the service.
SSO Protocols
SSO employs various protocols and standards to verify and authenticate users' credentials.
The primary ones are outlined below:
- SAML - a protocol for exchanging authentication information with an SSO service. Based on XML, it ensures high security as applications do not store user credentials.
- OAuth - an open standard allowing applications to access user data without transferring the password. It operates through API, establishing trust relationships between applications.
- OIDC - an approach where one set of credentials provides access to various sites. The service provider performs authentication, and applications request additional data to verify the user.
- Kerberos - an authentication system based on "tickets", protecting network participants' identities through cryptography.
Setting up the Server Application
Preliminary Steps
Next, contact the SmartPlayer team so they can enable this feature on the backend and also add its display on the frontend authentication page.
Additionally, the client's system administrator should send our team the configuration parameters:
SSO SAML certificate
SSO_SAML_LOGIN_URL
From our team's side, a metadata file is also sent.
Preparation:
Connect via ssh (or using other tools) to the remote server where the SmartPlayer server application is installed. Use the server's login and password.
Navigate to the folder where the SmartPlayer platform is installed.
По умолчанию это путь: “/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.
