Автор: Listen IT · YouTube · статья Nixys
Single Sign-On часто объясняют как «один пароль для всех приложений». Но главное изменение происходит не в пароле: приложения перестают самостоятельно проверять учётные данные и начинают доверять результату аутентификации в другой системе.
Ролик Listen IT показывает базовый сценарий SSO. Пользователь открывает приложение, перенаправляется к Identity Provider, проходит аутентификацию и возвращается с подтверждением личности. После этого другие приложения, включённые в ту же систему доверия, могут не запрашивать пароль повторно.
SSO при этом не является отдельным протоколом. Это желаемое поведение системы, которое можно реализовать через SAML или OpenID Connect. LDAP, Active Directory Domain Services и Active Directory Federation Services тоже появляются рядом с SSO, но решают задачи другого уровня: хранят пользователей, предоставляют доступ к каталогу или организуют федерацию.
Кому смотреть: разработчикам и системным аналитикам, которым нужно составить начальную карту технологий корпоративного входа.
Из этого можно взять в работу: для каждого приложения записать, кто именно проверяет пользователя и на основании какого сообщения приложение ему доверяет.
При локальной аутентификации каждое приложение хранит учётную запись, принимает пароль и создаёт собственную сессию. SSO выносит проверку пользователя в общий Identity Provider. Приложение становится Service Provider или relying party: оно принимает результат чужой аутентификации по заранее установленным правилам.
Это отличает SSO от password manager и так называемого Same Sign-On. Менеджер может подставлять сохранённые логин и пароль в разные формы, но каждое приложение всё равно самостоятельно проверяет эти данные. При настоящем SSO пароль получает только Identity Provider.
Доверие обычно подтверждается криптографически. В SAML передаётся подписанный assertion, в OpenID Connect — ID token. Называть любой объект в SSO просто JWT неточно: формат сообщения зависит от выбранного протокола.
Ролик быстро проходит несколько соседних технологий, поэтому важно не смешать их роли. OAuth 2.0 предназначен для делегирования доступа, а OpenID Connect добавляет поверх него идентификацию пользователя. LDAP позволяет читать и изменять каталог. AD DS хранит доменные учётные записи, а AD FS предоставляет федеративный вход в экосистеме Microsoft.
SSO сокращает количество форм входа и мест, где обрабатываются пароли, но повышает значение центрального провайдера. Его отказ способен закрыть вход сразу во множество приложений, а ошибка конфигурации — распространить неверное решение о доступе на всю систему.