Настройка единого входа (SSO)

Что такое SSO-подключение и как его настроить для вашего аккаунта.

Что такое SSO

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

Сотрудники смогут заходить в Servicepipe с теми же логином и паролем, что и в других рабочих сервисах. Доступами управляете вы: отключили человека в своей системе — он больше не сможет пройти аутентификацию в нашей панели.

Что такое SSO-подключение

SSO-подключение — это набор настроек для интеграции панели управления Servicepipe с вашей корпоративной системой аутентификации.

Вы создаёте такое подключение через наш интерфейс, экспортируете готовый файл с настройками, загружаете его в свою систему — и SSO работает.

Особенности и ограничения

  • Управлять настройками SSO могут только администраторы аккаунта.

  • Доступно два режима работы SSO-подключения: опциональный и принудительный. При «Опциональном SSO» пользователь сам решает, как зайти в панель (через SSO или по паролю). «Принудительный SSO» заставляет всех логиниться только через SSO — пользователи больше не могут входить по паролю.

  • В аккаунте может быть активно только одно SSO-подключение. Если вы добавили несколько подключений, только одно из них может работать — остальные будут в режиме «Выключено».

  • Пользователи не создаются автоматически при входе через SSO. Нужно создать их вручную: отправьте сотрудникам приглашения в аккаунт на их корпоративные имейлы — после этого они смогут входить через SSO.

  • Настройки SSO применяются ко всем пользователям аккаунта. Невозможно включить SSO для кого-то конкретного — оно включается/выключается сразу для всех.

  • Передача прав или ролей из сторонних систем не поддерживается. Например, если в вашей сети сотрудник — администратор, это не значит, что в нашей панели он тоже станет администратором. Пользователь входит с теми правами, которые вы ему назначили при создании. Права можно изменить в настройках.

  • Для сопоставления пользователей используется только имейл, другие данные при авторизации не учитываются. Проще говоря, в нашей системе и в вашей у пользователя должен быть указан один и тот же имейл — иначе он не сможет войти через SSO.

Как работает

В авторизации через SSO участвуют три стороны:

  • Пользователь — сотрудник компании, который заходит в панель управления.

  • Сервис-провайдер (Service Provider, SP) — сервис, который предоставляет услуги и запрашивает подтверждение личности. В данном случае это мы, Servicepipe.

  • Провайдер идентификации (Identity Provider, IdP) — ваша корпоративная система (например, Keycloak или ADFS), которая хранит данные сотрудников и подтверждает их личность.

Для взаимодействия используется протокол SAML 2.0. Обмен сообщениями происходит через браузер пользователя. После успешной аутентификации IdP передаёт SAML-ответ с помощью HTTP POST binding — данные ответа передаются в теле POST-запроса.

Учётные данные пользователя не покидают корпоративную систему, а SP получает только результат аутентификации. Ниже показано, как этот процесс выглядит на практике.

Схема работы SSO

Разберём каждый шаг подробнее:

  1. Пользователь на странице авторизации выбирает Войти через SSO и указывает корпоративный домен.

  2. SP проверяет, связан ли этот домен с настроенным SSO-подключением.

  3. SP формирует запрос на авторизацию (SAML AuthnRequest) и подписывает его своим приватным ключом.

    В параметрах ссылки для редиректа на сторону IdP передаются:

    • SAMLRequest — XML-запрос на авторизацию, закодированный в Base64.

    • SigAlg — алгоритм подписи (мы используем RSA-SHA256).

    • Signature — подпись, которую IdP должен проверить с помощью публичного сертификата SP.

    • RelayState — параметр, который IdP должен вернуть вместе с ответом на запрос.

    Пример запроса:
    https://idp.example.com/saml?SAMLRequest=***&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=***&RelayState=***

    Вместо символов *** в ссылке будут передаваться значения соответствующих параметров.

  4. IdP принимает запрос и проверяет его подпись с помощью публичного сертификата SP.

  5. Если подпись верна, IdP отображает пользователю форму для ввода учётных данных.

  6. Пользователь проходит аутентификацию на стороне IdP в соответствии с корпоративными политиками безопасности.

  7. После успешной аутентификации IdP формирует SAML-ответ, подписывает его своим приватным ключом и передаёт на адрес SP, полученный при настройке SSO.

    В теле POST-запроса мы ожидаем получить:

    • SAMLResponse — зашифрованный или незашифрованный XML-ответ в кодировке Base64.

    • RelayState — параметр, переданный SP вместе с запросом на аутентификацию. IdP должен вернуть его без изменений.

    Пример ответа:
    Content-Type: application/x-www-form-urlencoded
    
    SAMLResponse=***&RelayState=***

    Вместо символов *** будут передаваться значения соответствующих параметров.

    • Подпись ответа должна находиться внутри XML, передаваемого в параметре SAMLResponse.

    • Если параметр SAMLResponse или RelayState будет отсутствовать, система посчитает ответ невалидным и не сможет его обработать.

  8. SP получает SAML Response и проверяет подпись с помощью публичного сертификата IdP.

  9. SP проверяет, что ответ получен от доверенного IdP и ещё актуален. Если всё в порядке, извлекает корпоративный имейл и ищет по нему пользователя на своей стороне.

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

  • Если публичный сертификат или ID провайдера идентификации не соответствуют настройкам SSO, попытка входа будет отклонена.

  • Подпись ответа проверяется алгоритмом RSA-SHA256. Если IdP подпишет ответ другим методом, вход будет отклонён.

  • Мы принимаем как зашифрованные, так и незашифрованные XML-ответы. Если на стороне IdP включено шифрование данных пользователя (SAML Assertion), используйте публичный сертификат SP из SAML-метаданных и следующие алгоритмы:

    • AES-256-GCM или AES-256-CBC — для шифрования данных.

    • RSA-OAEP-MGF1P — для переноса ключа.

    • SHA-1 — для хеширования при переносе ключа.

Как настроить

Перед началом убедитесь, что:

  1. Ваша корпоративная система (IdP) настроена и готова к работе.

  2. В вашей системе созданы учётные записи сотрудников.

  3. Вы — администратор аккаунта в Servicepipe.

  4. Ваши сотрудники добавлены в панель управления Servicepipe под своими рабочими имейлами.

Шаг 1. Создайте SSO-подключение в Servicepipe

1. В панели управления откройте меню пользователя в верхнем правом углу и выберите Настройки аккаунта.

Переход в настройки аккаунта

2. Перейдите на вкладку Аутентификация и нажмите кнопку Создать SSO-подключение.

Кнопка создания SSO-подключения

3. В открывшемся окне заполните все поля.

В данном случае провайдер идентификации (IdP) — это ваша корпоративная система, а провайдер услуг — мы (Servicepipe).

Название поля Описание Где взять данные Пример

ID провайдера идентификации

Уникальный идентификатор IdP

В настройках на стороне IdP

https://idp.example.com/entity

URL страницы авторизации

Адрес страницы вашего провайдера идентификации, куда Servicepipe перенаправит пользователя для входа

В настройках на стороне IdP

https://idp.example.com/samlsso

Публичный сертификат
провайдера
идентификации

Публичный сертификат вашего провайдера в формате PEM.

Нужен для проверки подписей SAML-ответов.

Что такое формат PEM?

PEM (Privacy-Enhanced Mail) — это текстовый формат для хранения криптографических ключей и сертификатов. Данные в этом формате представлены в кодировке Base64 и обрамлены строками вида -----BEGIN…----- и -----END…-----.

В настройках на стороне IdP

-----BEGIN CERTIFICATE-----
BgkqhkiG9w0BAQsFADBvMQswCQY
DVQQGEwJVUzELMAkMIIDAUz3Xdz
CCAl+gAwIBGEwJVUzELMAkMIIDA
Uz3XdzCCAl+gAwIBBgkqhkiG9w0
BAQsFADBvMQswCQYDVQQA1UECAw
CgIEEzANG
-----END CERTIFICATE-----

Публичный сертификат провайдера услуг

Публичный сертификат Servicepipe в формате PEM.

Используется провайдером идентификации для проверки подписи SAML-запросов.

Сгенерируйте самостоятельно.

Это не готовый файл, его нужно создать с нуля — например, в настройках IdP или через сторонний генератор сертификатов.

Созданный вами сертификат и будет считаться сертификатом Servicepipe.

Данные сертификата должны быть разделены на строки по 64 символа.

-----BEGIN CERTIFICATE-----
BgkqhkiG9w0BAQsFADBvMQswCQY
DVQQGEwJVUzELMAkMIIDAUz3Xdz
CCAl+gAwIBGEwJVUzELMAkMIIDA
Uz3XdzCCAl+gAwIBBgkqhkiG9w0
BAQsFADBvMQswCQYDVQQA1UECAw
CgIEEzANG
-----END CERTIFICATE-----

Приватный ключ провайдера услуг

Приватный ключ Servicepipe в формате PEM.

Используется для подписи SAML-запросов.

Используйте ключ, который был создан вместе с сертификатом выше. Данные ключа должны быть разделены на строки по 64 символа.

Ключ хранится на стороне Servicepipe и не передаётся провайдеру идентификации.

-----BEGIN RSA PRIVATE KEY-----
BgkqhkiG9w0BAQsFADBvMQswCQY
DVQQGEwJVUzELMAkMIIDAUz3Xdz
CCAl+gAwIBGEwJVUzELMAkMIIDA
Uz3XdzCCAl+gAwIBBgkqhkiG9w0
BAQsFADBvMQswCQYDVQQA1UECAw
CgIEEzANG
-----END RSA PRIVATE KEY-----

Корпоративные доменные имена

Ваши корпоративные домены, связанные с этим SSO-подключением.

По ним Servicepipe определяет, какой провайдер идентификации использовать при входе пользователя.

Укажите домены вручную через запятую.

Домены должны быть уникальны в рамках системы.

example.ru, ex.org

Состояние SSO

Режим работы SSO-подключения. Определяет, как пользователи могут входить в сервис.

Выберите вариант из списка:

Выключено — SSO-подключение сохранено в системе, но не используется для входа.

Опциональный SSO — пользователь может войти как через SSO, так и с помощью имейла и пароля. Рекомендуем использовать на этапе настройки и проверки подключения.

Принудительный SSO — пользователь может войти только через SSO. Недоступны авторизация по имейлу и паролю, смена пароля и изменение настроек 2FA. Используйте после полной настройки и успешного тестирования SSO.

Опциональный SSO

4. Когда все поля будут заполнены, нажмите кнопку Создать.

Создание SSO-подключения

Подключение появится в списке на вкладке Аутентификация.

Шаг 2. Завершите настройку на стороне IdP

Теперь нужно передать настройки SSO-подключения вашему провайдеру идентификации. Для этого используются SAML-метаданные — XML-файл с технической информацией, который поможет:

  • распознать Servicepipe как доверенный сервис;

  • определить адрес, на который нужно отправлять SAML-ответы;

  • использовать корректные параметры и сертификаты при обмене данными.

Что нужно сделать:

  1. На вкладке Аутентификация нажмите иконку скачивания над списком SSO-подключений. Она появляется после создания первого подключения.

  2. Загрузите полученный файл в настройки вашего провайдера идентификации.

Иконка скачивания SAML-метаданных

Шаг 3. Проверьте авторизацию

После заполнения всех параметров в Servicepipe и на стороне провайдера идентификации убедитесь, что авторизация работает. Для этого:

  1. Перейдите на страницу авторизации и выберите Войти через SSO.

  2. В поле Корпоративный домен укажите домен, который вы задали в настройках SSO-подключения.

  3. Нажмите Войти через SSO.

  4. На странице провайдера идентификации введите корпоративные учётные данные.

Если всё настроено корректно, после аутентификации вы попадёте в панель управления.

Если вход не работает, убедитесь, что:

  • домен указан без ошибок и совпадает с доменом в настройках SSO-подключения;

  • SSO-подключение создано и включено;

  • SAML-метаданные загружены в провайдер идентификации;

  • введённые учётные данные действительны на стороне IdP.

Если после проверки вход по SSO по-прежнему не работает, напишите нам на support@servicepipe.ru — поможем разобраться.

Как управлять

На вкладке Аутентификация можно управлять подключением прямо из списка:

  • Редактирование: нажмите на многоточие (…) в конце строки и выберите Редактировать. Здесь вы сможете изменить параметры подключения.

    У существующего SSO-подключения нельзя изменить ID провайдера идентификации. Если нужно указать другой идентификатор, удалите текущее подключение и создайте новое.

  • Удаление: нажмите на многоточие (…), выберите Удалить и подтвердите удаление. Восстановить удалённое подключение невозможно.

Действия для SSO-подключений