SCIM и SAML: в чём разница и зачем нужны оба

SCIM и SAML относятся к управлению доступом, но решают разные задачи, и путаница между ними приводит к вполне конкретной уязвимости.

SAML отвечает на вопрос «кто сейчас входит». Это протокол аутентификации, обеспечивающий единый вход.

SCIM отвечает на вопрос «какие учётные записи должны существовать». Это стандарт синхронизации учётных записей между системами.

Первый работает в момент входа. Второй — когда меняются данные о сотруднике.

Сравнение

	SAML	SCIM
Задача	Аутентификация, единый вход	Создание и синхронизация учётных записей
Когда срабатывает	При входе пользователя	При изменении данных о сотруднике
Формат	XML	JSON поверх REST
Что происходит без него	Пользователь не может войти централизованно	Учётные записи расходятся с реальностью
Основной эффект	Меньше паролей, единая точка входа	Нет забытых и осиротевших учётных записей

Почему одного недостаточно

Рассмотрим ситуацию, которая встречается регулярно.

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

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

Это и есть брешь, которую закрывает SCIM: он не просто перестаёт пускать через центральную точку, а отключает записи в самих приложениях.

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

Что важно учитывать

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

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

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

Практический вывод

Полная схема состоит из трёх частей:

1. Единый вход — чтобы пользователь входил один раз и надёжно.
2. Синхронизация учётных записей — чтобы в приложениях не оставалось лишнего.
3. Управление сессиями — чтобы прекращение доступа было немедленным, а не отложенным до истечения токена.

Первые два пункта решают SAML и SCIM. Третий обеспечивает провайдер идентичности.

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

Keydee закрывает вход и управление доступом в границах организации:

• Подключение приложений по OIDC — современная альтернатива SAML, проще в интеграции и лучше работающая с мобильными клиентами.
• Управление составом организации: приглашение сотрудника, изменение ролей, исключение — через кабинет и API.
• Права передаются приложениям в токене, поэтому изменение ролей применяется централизованно.
• Завершение сессий прекращает доступ немедленно — это тот самый третий пункт, который не закрывается синхронизацией учётных записей.
• Журнал фиксирует изменения состава и прав.

Короткий вывод

Вопрос «SCIM или SAML» некорректен так же, как вопрос «замок или сигнализация».

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