SSO в B2B-сервисе: как связать вход, компанию и роли

SSO в B2B-сервисе нужно проектировать как связь внешней личности с конкретной компанией и её правилами доступа. Успешный корпоративный вход сам по себе не назначает роль администратора и не даёт права на чужие данные. До подключения провайдера определите, кто подтверждает организацию, как назначаются полномочия и как владелец восстановит управление при недоступности обычного входа.

Три решения, скрытые за кнопкой входа

Первое решение — доверять ли подтверждению личности от выбранного провайдера. Второе — состоит ли этот человек в нужной клиентской организации. Третье — разрешено ли ему конкретное действие. Если собрать их в один признак «успешно вошёл», легко выдать больше возможностей, чем согласовал заказчик. Особенно когда пользователь работает с несколькими компаниями в одном кабинете.

В описании Microsoft Entra федеративный SSO представлен как проверка пользователя поставщиком удостоверений и передача сведений приложению через стандартные протоколы. Среди вариантов названы SAML и OpenID Connect. Ниже речь именно о таком корпоративном подключении, а не о сохранении пароля в менеджере или простой ссылке на другое приложение.

Для собственного SaaS удобно записать эти решения отдельно: проверенное подключение провайдера, связь внешнего пользователя с локальным участником и полномочия в выбранной организации. Конкретные поля зависят от протокола. Не сопоставляйте людей только по отображаемому имени и не делайте совпадение почтового домена достаточным основанием для административного доступа.

Подключение компании начинается до первого входа

Настройку должен инициировать человек с подтверждёнными полномочиями управлять организацией в сервисе. Ему показывают, какое пространство подключается и какие правила изменятся. Администратор другой компании не должен иметь возможность заменить провайдера соседа через изменение адреса в запросе. Это проверяют на стороне приложения, а не только скрытием кнопки.

Зафиксируйте доверенного поставщика, параметры протокола и порядок изменения конфигурации. Проверка технической корректности подключения не заменяет подтверждение бизнес-полномочий. Поддержка не должна переключать организацию на новый провайдер только потому, что заявитель умеет прислать рабочий файл настроек. Нужна заранее согласованная процедура с проверкой владельца.

Затем выберите способ появления участников. Можно заранее создавать членство, подтверждать приглашение либо разрешать появление пользователя при первом входе по установленным правилам. Последний вариант требует особенно ясного ограничения: какие подтверждённые атрибуты дают право присоединиться и какую минимальную роль получает новый участник. Это решение продукта, а не неизбежное свойство SSO.

Матрица допуска: одного подтверждения личности мало

Таблица — собственный набор сценариев для приёмки. Источник роли в ней является выбранной политикой сервиса: его нужно определить до интеграции и не смешивать незаметно с ручными исключениями.

Откуда берутся роли и кто может их менять

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

Отдельно решите, разрешены ли локальные исключения и когда они истекают. Иначе временный доступ, выданный поддержкой, переживёт изменение должности сотрудника. В журнале должно быть понятно, почему у человека появилась роль: внешняя группа, подтверждённое приглашение или ручное решение конкретного администратора. Участнику полезно видеть текущую организацию, особенно при переключении контекста.

Увольнение проверяют вместе с действующей сессией

Запрет нового входа и прекращение уже открытой сессии — разные задачи. Выберите, каким способом приложение узнаёт об отключении сотрудника и когда пересматривает действующие права. Не обещайте мгновенный отзыв во всех системах, если реализована только проверка при следующем входе. Для важных операций проверяйте актуальное членство по принятой модели, а не старую подпись в интерфейсе.

В тестовом сценарии участник открывает документ, затем администратор снимает его роль. Нужно проверить повторное чтение, сохранение, экспорт и фоновую операцию. Цель — увидеть фактическую границу отзыва. Если часть действий завершается по прежним правам, это должно соответствовать согласованным требованиям; нельзя оставлять такое поведение необнаруженным до первого кадрового изменения.

Аварийный доступ без общего запасного пароля

Предусмотрите ситуацию, когда провайдер недоступен, но нужно управлять собственным сервисом. В рекомендациях Microsoft по аварийным аккаунтам отдельно рассматривается отказ федерации; подчёркиваются независимость аварийного пути, сильная аутентификация и контроль использования. Это правила конкретной среды, которые нельзя механически переносить в любое приложение.

Для своего SaaS согласуйте круг уполномоченных лиц, независимые средства подтверждения и процедуру включения такого доступа. Общее требование «отключить проверки, если SSO упал» создаёт опасный обход. Аварийный путь нужно ограничить по назначению, защитить и заранее испытать. Его применение должно оставлять проверяемые события, доступные ответственным за безопасность.

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

Приёмка корпоративного подключения

1. Согласуйте границу клиентской организации, владельца настройки и допустимые способы подтверждения его полномочий.
2. Опишите доверенные подключения и сопоставление внешней личности с локальным участником. Проверьте вход человека из другого пространства.
3. Выберите единственный понятный порядок назначения ролей либо явно опишите приоритет нескольких источников.
4. Испытайте нового участника, неизвестную группу, изменение должности и отключение уже вошедшего сотрудника.
5. Проверьте отказ провайдера без автоматического открытия доступа всем пользователям. Отдельно испытайте защищённую аварийную процедуру.
6. Передайте владельцу карту ролей, порядок изменений, журнал событий и инструкцию восстановления.

Эти требования стоит включить в разработку SaaS, а связь с кадровыми и учётными процессами — в автоматизацию. Для независимой проверки границ компаний подойдёт аудит личного кабинета. Критерий готовности — правильное решение для каждой строки матрицы, а не только успешное открытие стартового экрана.