Что такое SCIM и зачем нужен автоматический провижининг

SCIM (System for Cross-domain Identity Management) — открытый стандарт, по которому системы обмениваются данными об учётных записях: создают их, обновляют и отключают. Это не протокол входа. SCIM не проверяет пароли и не выдаёт токенов — он следит за тем, чтобы во всех приложениях были правильные пользователи с правильными правами.

Разделение простое: вход обеспечивает SSO, актуальность учётных записей — SCIM.

Проблема ручного управления

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

Сотрудник переходит в другой отдел — права нужно поменять в тех же десяти местах. Обычно меняют в трёх, где вспомнили, а старые доступы остаются.

Сотрудник увольняется — учётные записи надо отключить. И вот здесь ручной подход даёт самый неприятный результат: где-то доступ остаётся. Не по злому умыслу, а потому что список систем никто не вёл.

Такие «осиротевшие» учётные записи — одна из типовых причин инцидентов. Формально человек уволен, фактически может войти.

Что делает SCIM

Создаёт учётные записи автоматически. Данные о новом сотруднике попадают в провайдер идентичности, тот рассылает их подключённым приложениям. Доступ появляется в день выхода, а не через неделю.

Синхронизирует изменения. Смена фамилии, отдела, должности или состава групп распространяется на все системы без ручного вмешательства.

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

Управляет группами. Права выдаются не поштучно, а через членство в группе — это заметно снижает число ошибок.

Как это работает технически

SCIM использует REST API и JSON — тот же набор технологий, что и обычные веб-интеграции. Провайдер идентичности выступает источником истины: при любом изменении он отправляет приложениям запросы на создание, обновление или отключение записи.

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

SCIM и SAML: разные задачи

Их часто упоминают вместе, из-за чего возникает путаница.

	SAML / OIDC	SCIM
Отвечает на вопрос	Кто сейчас входит?	Какие учётные записи должны существовать?
Когда работает	В момент входа	При изменении данных о сотруднике
Что происходит без него	Пользователь не может войти	Учётные записи расходятся с реальностью

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

Поэтому связка «SSO для входа + SCIM для учётных записей» закрывает задачу целиком, тогда как каждый компонент по отдельности оставляет зазор.

Где обычно ошибаются

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

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

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

Не смотрят журналы синхронизации. Неудачная синхронизация проходит незаметно, и расхождение обнаруживается через месяцы.

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

Как это устроено в Keydee

Keydee управляет составом сотрудников на уровне организации, и связанные с этим операции доступны через API и кабинет:

• Приглашение сотрудника в организацию с назначением ролей.
• Изменение ролей — права меняются централизованно и сразу отражаются в токенах приложений.
• Отключение и удаление сотрудника из организации.
• Немедленный отзыв доступа. Помимо отключения учётной записи, можно завершить активные сессии — доступ прекращается сразу, не дожидаясь истечения токена. Это тот самый зазор, который SCIM сам по себе не закрывает.
• Журнал изменений фиксирует, кто и когда менял состав и права.

С чего начать

1. Определите источник истины о сотрудниках: кадровая система, каталог или ручной ввод. Без ясного ответа автоматизация превратится в рассинхронизацию.
2. Составьте список приложений и выясните, какие из них поддерживают автоматический провижининг.
3. Начните с самых массовых систем — там ручная работа отнимает больше всего времени.
4. Обязательно проверьте сценарий увольнения на тестовом пользователе.
5. Настройте контроль журналов синхронизации, чтобы сбои не проходили незамеченными.