Единый вход нужен не ради одной кнопки авторизации. Его задача — позволить компании централизованно открывать и закрывать вход сотрудников через корпоративную учётную запись. Для этого недостаточно подключить провайдера идентификации: нужно связать учётные записи, отдельно настроить роли и проверить, что происходит после отключения человека.
Главный принцип: успешная настройка SSO ещё не доказывает, что отключённый пользователь потеряет все способы доступа. Новый вход, уже открытая сессия, локальная учётная запись, роли в проектах и технические доступы workflow проверяются отдельно.
Когда компании нужен единый вход в n8n
SSO стоит рассматривать, если в n8n работают несколько сотрудников, компания уже использует корпоративного провайдера идентификации, кадровые изменения происходят регулярно или службе ИБ нужно управлять входом из одного контура.
SSO не обязателен для любой установки. Для небольшой изолированной среды отдельная схема может оказаться соразмернее. Решение зависит от размещения n8n, редакции, числа категорий пользователей, действующих способов входа и требований к отключению доступа.
Единый вход может сократить число независимых способов аутентификации, если команда отдельно учтёт локальный и резервный вход. При этом SSO не отвечает автоматически на два вопроса:
- какие действия сотруднику разрешены внутри экземпляра и проектов;
- что произойдёт с уже открытой сессией после отключения записи у провайдера идентификации.
Поэтому до настройки сформулируйте проверяемый результат. Например: «После отключения корпоративной записи сотрудник не может начать новую сессию; поведение действующей сессии соответствует согласованному правилу; резервный вход доступен только назначенному ответственному».
Что n8n подтверждённо поддерживает
Согласно официальной документации n8n, платформа поддерживает SSO по протоколам SAML и OIDC. Функция доступна в n8n Cloud Enterprise, а при самостоятельном размещении — в редакциях Business и Enterprise. Включать и настраивать SSO должен владелец экземпляра или администратор.
Начиная с n8n 2.18.0 документация также предусматривает конфигурацию SSO через переменные окружения вместо интерфейса. Этот факт не означает, что такой способ подходит к любой схеме развёртывания: состав переменных, порядок активации и управление конфигурацией нужно сверить для выбранной версии.
Перед проектированием зафиксируйте:
| Что проверить | Зачем это нужно |
|---|---|
| Cloud или self-hosted | Определяет контур управления и доступные варианты редакции |
| Версия и редакция n8n | Подтверждает доступность нужной функции |
| SAML или OIDC | Задаёт протокол взаимодействия с IdP |
| Права владельца или администратора | Определяет, кто может менять настройку |
| Выбранный IdP и его конфигурация | Нужны для проверки атрибутов и отключения пользователя |
- Что проверить
- Cloud или self-hosted
- Зачем это нужно
- Определяет контур управления и доступные варианты редакции
- Что проверить
- Версия и редакция n8n
- Зачем это нужно
- Подтверждает доступность нужной функции
- Что проверить
- SAML или OIDC
- Зачем это нужно
- Задаёт протокол взаимодействия с IdP
- Что проверить
- Права владельца или администратора
- Зачем это нужно
- Определяет, кто может менять настройку
- Что проверить
- Выбранный IdP и его конфигурация
- Зачем это нужно
- Нужны для проверки атрибутов и отключения пользователя
Документация подтверждает поддержку протоколов и условия доступности функции. Она не доказывает совместимость с любым IdP, правильное сопоставление атрибутов или нужное поведение активной сессии в конкретной среде.
Спроектируйте связь корпоративной и внутренней учётной записи
До подключения SSO составьте карту идентичности пользователя. Она должна отвечать не только на вопрос «какой email передаёт IdP», но и на вопрос «как n8n понимает, что это тот же человек».
Зафиксируйте для каждой категории пользователей:
| Поле карты | Что решить |
|---|---|
| Устойчивый идентификатор | Какой атрибут однозначно обозначает человека |
| Рабочий email | Откуда он поступает и может ли измениться |
| Источник атрибутов | Какая система считается основной |
| Первый вход | Должна ли появляться внутренняя запись и кто разрешает доступ |
| Совпадение с локальной записью | Как проверить конфликт до включения SSO |
| Изменение email | Как подтвердить, что вход относится к прежнему человеку |
| Отключение | Какие состояния должны измениться и кто это проверяет |
- Поле карты
- Устойчивый идентификатор
- Что решить
- Какой атрибут однозначно обозначает человека
- Поле карты
- Рабочий email
- Что решить
- Откуда он поступает и может ли измениться
- Поле карты
- Источник атрибутов
- Что решить
- Какая система считается основной
- Поле карты
- Первый вход
- Что решить
- Должна ли появляться внутренняя запись и кто разрешает доступ
- Поле карты
- Совпадение с локальной записью
- Что решить
- Как проверить конфликт до включения SSO
- Поле карты
- Изменение email
- Что решить
- Как подтвердить, что вход относится к прежнему человеку
- Поле карты
- Отключение
- Что решить
- Какие состояния должны измениться и кто это проверяет
Не предполагайте без проверки, что n8n автоматически создаст, объединит, удалит или деактивирует нужную запись. Эти действия зависят от фактической конфигурации и должны войти в сценарий испытания.
Для владельца self-hosted экземпляра действует отдельное документированное правило: смена его email обновляет существующую учётную запись владельца. Она не передаёт владение другому существующему пользователю и не объединяет аккаунты. Поэтому изменение адреса владельца нельзя использовать как процедуру передачи ответственности.
Отделите вход от полномочий в n8n
Аутентификация отвечает на вопрос «может ли человек войти». Роли отвечают на вопрос «что он может делать после входа». Эти проверки нельзя объединять в одну.
В n8n есть роли уровня экземпляра и роли проектов. Первые определяют действия во всём экземпляре, вторые — действия внутри конкретного проекта. Один пользователь может иметь разные роли в разных проектах. Доступность отдельных проектных ролей зависит от редакции n8n.
Составьте матрицу полномочий до настройки:
| Категория пользователя | Нужные проекты | Допустимые действия | Кто согласует |
|---|---|---|---|
| Владелец экземпляра | Весь экземпляр | Управление экземпляром и назначенными проектами | Ответственный за платформу |
| Администратор | По принятой схеме | Администрирование в согласованных границах | Владелец экземпляра |
| Сотрудник | Только рабочие проекты | Действия по должностной задаче | Владелец проекта |
| Аварийный доступ | Заранее определённый контур | Только действия для восстановления | Назначенный ответственный |
- Категория пользователя
- Владелец экземпляра
- Нужные проекты
- Весь экземпляр
- Допустимые действия
- Управление экземпляром и назначенными проектами
- Кто согласует
- Ответственный за платформу
- Категория пользователя
- Администратор
- Нужные проекты
- По принятой схеме
- Допустимые действия
- Администрирование в согласованных границах
- Кто согласует
- Владелец экземпляра
- Категория пользователя
- Сотрудник
- Нужные проекты
- Только рабочие проекты
- Допустимые действия
- Действия по должностной задаче
- Кто согласует
- Владелец проекта
- Категория пользователя
- Аварийный доступ
- Нужные проекты
- Заранее определённый контур
- Допустимые действия
- Только действия для восстановления
- Кто согласует
- Назначенный ответственный
SSO само по себе не следует считать механизмом автоматического назначения ролей или удаления членства в проектах. Если такое поведение требуется, его нужно отдельно спроектировать и проверить. Подробный разбор полномочий вынесен в руководство о ролях и доступах в n8n.
Разделите человеческие и технические учётные записи
Отключение сотрудника не должно случайно останавливать рабочие процессы. Для этого сначала выясните, какие доступы принадлежат человеку, а какие обеспечивают выполнение workflow.
Проведите инвентаризацию:
- владельца экземпляра и администраторов;
- обычных сотрудников;
- аварийного способа входа и его владельца;
- сервисных аккаунтов;
- внешних credentials, которые используют workflow;
- личных доступов сотрудников, от которых пока зависят процессы.
Целевое требование можно сформулировать так: критичные workflow используют отдельно назначенные технические доступы и продолжают работать после отключения корпоративной записи сотрудника. Это именно требование к будущему контуру, а не утверждение о текущей установке.
Если workflow всё ещё зависит от личной записи, одного изменения SSO недостаточно. Потребуется отдельная процедура передачи процессов, секретов и ответственности. Она описана в руководстве об отключении пользователя и передаче его работы.
Спроектируйте отключение доступа
Заранее согласуйте последовательность действий и ожидаемые состояния:
- Уполномоченный специалист отключает корпоративную запись у IdP.
- Проверяющий пытается начать новую сессию через SSO.
- Команда проверяет ранее открытую сессию по согласованному критерию.
- Проверяющий перебирает учтённые локальные и резервные способы входа.
- Владелец проекта проверяет членство и роли отдельно от аутентификации.
- Ответственный подтверждает работу критичных workflow с техническими доступами.
Не закладывайте неподтверждённые ожидания: отключение пользователя у IdP нельзя заранее считать удалением его записи из n8n, завершением всех сессий, отзывом локального входа или удалением ролей. Желаемое поведение сначала записывают как требование, а затем сравнивают с наблюдаемым результатом.
Для каждого шага назначьте ответственного и источник наблюдения. Служба ИБ может подтвердить состояние записи у IdP, администратор n8n — доступ и роли, а владелец процесса — работу workflow. Так команда не подменит проверку одной системы предположением о состоянии другой.
Условный сценарий проверки отключения
Ниже — синтетический пример для подготовки испытания. Это не клиентский кейс Switch On AI и не результат выполненного теста.
Условная компания использует корпоративный IdP и self-hosted n8n подходящей редакции. Сотрудник входит по SSO и имеет заранее согласованную роль в рабочем проекте. Затем уполномоченный специалист отключает его корпоративную запись.
| Шаг | Ожидаемый результат | Фактический результат | Источник наблюдения | Решение ответственного |
|---|---|---|---|---|
| Исходный вход | Сотрудник начинает сессию через корпоративный SSO | Заполняется при проверке | Журнал IdP и состояние входа в n8n | Подтвердить исходное состояние или остановить испытание |
| Проверка роли | Пользователь видит только согласованный проект и действия | Заполняется при проверке | Членство и роль в выбранном проекте | Исправить полномочия до проверки отключения |
| Отключение записи | IdP показывает отключённое состояние | Заполняется при проверке | Запись пользователя у IdP | Зафиксировать время и исполнителя действия |
| Новый вход | Отключённая запись не начинает новую сессию | Заполняется при проверке | Результат входа и журнал IdP | При доступе зафиксировать несоответствие и выяснить маршрут входа |
| Открытая сессия | Поведение соответствует заранее согласованному требованию | Заполняется при проверке | Существующая сессия n8n | Принять результат либо изменить настройку и повторить проверку |
| Локальный или резервный вход | Доступ остаётся только у разрешённого аварийного владельца | Заполняется при проверке | Попытка входа каждым учтённым способом | Закрыть неучтённый маршрут или оформить исключение |
| Работа workflow | Критичные процессы с техническими доступами продолжают работу | Заполняется при проверке | Выполнение согласованного контрольного workflow | Разобрать зависимость от личной записи при остановке |
- Шаг
- Исходный вход
- Ожидаемый результат
- Сотрудник начинает сессию через корпоративный SSO
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Журнал IdP и состояние входа в n8n
- Решение ответственного
- Подтвердить исходное состояние или остановить испытание
- Шаг
- Проверка роли
- Ожидаемый результат
- Пользователь видит только согласованный проект и действия
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Членство и роль в выбранном проекте
- Решение ответственного
- Исправить полномочия до проверки отключения
- Шаг
- Отключение записи
- Ожидаемый результат
- IdP показывает отключённое состояние
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Запись пользователя у IdP
- Решение ответственного
- Зафиксировать время и исполнителя действия
- Шаг
- Новый вход
- Ожидаемый результат
- Отключённая запись не начинает новую сессию
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Результат входа и журнал IdP
- Решение ответственного
- При доступе зафиксировать несоответствие и выяснить маршрут входа
- Шаг
- Открытая сессия
- Ожидаемый результат
- Поведение соответствует заранее согласованному требованию
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Существующая сессия n8n
- Решение ответственного
- Принять результат либо изменить настройку и повторить проверку
- Шаг
- Локальный или резервный вход
- Ожидаемый результат
- Доступ остаётся только у разрешённого аварийного владельца
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Попытка входа каждым учтённым способом
- Решение ответственного
- Закрыть неучтённый маршрут или оформить исключение
- Шаг
- Работа workflow
- Ожидаемый результат
- Критичные процессы с техническими доступами продолжают работу
- Фактический результат
- Заполняется при проверке
- Источник наблюдения
- Выполнение согласованного контрольного workflow
- Решение ответственного
- Разобрать зависимость от личной записи при остановке
Если новый вход остаётся возможным, это ещё не доказывает неисправность n8n. Сначала проверьте источник активной сессии, наличие локальной записи, альтернативный маршрут аутентификации и фактическую конфигурацию IdP. Результат следует оформить как несоответствие проектному требованию с наблюдаемыми данными.
Приёмка, ограничения и передача в эксплуатацию
Контур можно принимать, когда команда проверила не только успешный вход, но и прекращение доступа. Используйте критерии:
- только разрешённая корпоративная запись начинает новую SSO-сессию;
- отключённая запись не может начать новую сессию;
- действующая сессия ведёт себя по согласованному правилу;
- локальные и резервные способы входа перечислены и проверены;
- роли и членство в проектах проверены отдельно;
- критичные workflow не зависят от личной записи отключаемого сотрудника;
- владелец аварийного доступа назначен;
- ограничения и обнаруженные обходные маршруты зафиксированы.
В эксплуатационном документе сохраните версию, редакцию и вариант размещения n8n, выбранный протокол, конфигурацию IdP без секретов, категории пользователей, проверенные сценарии, ожидаемые и фактические результаты, ответственных и известные ограничения. Документация продукта подтверждает доступные функции, но не заменяет испытание конкретной настройки.
Switch On AI помогает разбирать процессы и разрабатывать автоматизацию с проверяемыми критериями. Для задачи с n8n можно обсудить схему текущего входа, требования к отключению и ограниченный прототип ключевого сценария на странице услуг Switch On AI. Прототип помогает согласовать требования, но не считается готовым внедрением.
Для первого обсуждения подготовьте вариант размещения и редакцию n8n, используемый IdP, категории пользователей, действующие способы входа и ожидаемое поведение после отключения сотрудника. Затем можно определить границы разработки и сценарии приёмки.
Вопросы по этой задаче
Чем SSO отличается от ролей и доступов в n8n?
SSO подтверждает личность и определяет возможность входа. Роли уровня экземпляра и проекта определяют действия после входа. Настройку аутентификации и проверку полномочий нужно проводить отдельно.
Закроется ли уже открытая сессия после отключения пользователя у провайдера идентификации?
Предоставленные источники не подтверждают универсальное поведение действующей сессии. Команда должна заранее согласовать требование и проверить его в своей версии, редакции и конфигурации n8n и IdP.
Можно ли оставить аварийный способ входа без корпоративного SSO?
Такой способ можно включить в проектные требования, если назначены его владелец, условия применения и порядок проверки. Нельзя оставлять неучтённый локальный вход, который позволяет обойти отключение корпоративной записи.
Что произойдёт с workflow и credentials после отключения учётной записи сотрудника?
SSO само по себе не подтверждает остановку, передачу или отзыв доступов workflow. Нужно проверить, какие процессы зависят от личной записи, и по возможности назначить им отдельные технические доступы.
Поддерживает ли n8n любой корпоративный провайдер SAML или OIDC?
Документация подтверждает поддержку протоколов SAML и OIDC, но не гарантирует совместимость с любым конкретным IdP. Совместимость, атрибуты и сценарий отключения проверяют для выбранной конфигурации.