Технология Single Sign-On (SSO), единый вход, давно стала стандартом де-факто для корпоративных ИТ-ландшафтов и современных веб-сервисов. Но за простой фразой «один логин на все» скрывается сложная экосистема участников, протоколов и правил. В этой статье подробно разберем, кто именно попадает в SSO: какие сущности участвуют в процессе, какие роли они играют и как определяются границы зоны действия единого входа.

Ключевые акторы архитектуры SSO

Любая реализация SSO строится на взаимодействии трех фундаментальных сторон. Понимание их ролей, ключ к ответу на вопрос «кто попадает в SSO».

Субъект (User / Principal), «Кто входит»

Это конечный пользователь, который инициирует процесс аутентификации. В контексте SSO «попадает» в систему не просто абстрактный юзер, а конкретные категории лиц:

• Внутренние сотрудники (Workforce): Полноштатные работники, подрядчики, стажеры. Их учетные записи управляются корпоративным каталогом (AD, Entra ID, Okta, Google Workspace).
• Внешние партнеры и поставщики (B2B / External Identities): Пользователи из других организаций, которым нужен доступ к вашим ресурсам (порталам поставщиков, CRM, репозиториям). Часто аутентифицируются через федерацию идентификаторов (SAML/OIDC) со своим IdP.
• Клиенты и потребители (CIAM — Customer Identity and Access Management): Пользователи публичных сервисов (интернет-банкинг, маркетплейсы, SaaS-продукты). Для них SSO часто означает «Войти через Google/Apple/Microsoft» или единый аккаунт внутри экосистемы бренда.
• Сервисные аккаунты и боты (Non-human identities): Скрипты, микросервисы, CI/CD пайплайны. Они «попадают» в SSO через механизмы Machine-to-Machine (M2M) аутентификации (Client Credentials Flow в OAuth 2.0 / OIDC), получая токены доступа без интерактивного логина.

Провайдер идентичности (Identity Provider — IdP) — «Кто подтверждает»

Центральный авторитет, хранящий учетные данные и выполняющий аутентификацию. Именно IdP определяет политику: кто имеет право войти, как (пароль, MFA, биометрия, FIDO2 ключ) и сколько времени действует сессия.

Примеры: Microsoft Entra ID (Azure AD), Okta, Ping Identity, Keycloak, Auth0, Google Cloud Identity, AWS IAM Identity Center.

В предоставленном примере с LinkedIn и Google роль IdP выполняет Google.

Провайдер сервиса (Service Provider — SP) / Relying Party (RP) — «Кто доверяет»

Приложение или ресурс, к которому пользователь хочет получить доступ. SP не проверяет пароль напрямую, а доверяет утверждению (Assertion/Token), выданному IdP;

• Корпоративные приложения (SaaS): Salesforce, Slack, Zoom, GitHub Enterprise, Jira, Confluence, Office 365.
• On-premise / Legacy приложения: Старые системы, интегрированные через Web Access Management (WAM), Kerberos/SPNEGO или Application Proxies.
• Собственные разработки (Custom Apps): Микросервисы, SPA, мобильные приложения, защищенные через OIDC/OAuth2.
• Инфраструктура: VPN, SSH-бастионы, Kubernetes API, базы данных (через IAM аутентификацию).

В примере выше роль SP выполняет LinkedIn.

Что «попадает» в зону действия SSO (Scope)

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

Приложения, интегрированные по протоколам

Приложение считается «попавшим в SSO», только если оно поддерживает один из стандартных протоколов федерации:

1. SAML 2.0 (Security Assertion Markup Language): Классика для Enterprise SaaS. Обмен XML-ассерциями через браузер (HTTP Redirect/POST Binding).
2. OpenID Connect (OIDC) / OAuth 2.0: Современный стандарт для веба, мобильных приложений и API. Работает с JSON Web Tokens (JWT), ID Token и Access Token.
3. WS-Federation / WS-Trust: Устаревающий стандарт, встречается в старых .NET приложениях и AD FS.
4. Kerberos / Integrated Windows Authentication (IWA): Для бесшовного входа в доменные приложения внутри корпоративной сети (Desktop SSO).

Атрибуты и Клеймы (Claims / Attributes)

При входе через SSO в SP «попадает» набор атрибутов пользователя, необходимых для авторизации (RBAC/ABAC) и персонализации:

• Идентификатор (NameID / sub / userPrincipalName).
• Роли и группы (Groups claim / Roles claim).
• Email, ФИО, телефон, отдел, менеджер.
• Кастомные атрибуты (Cost Center, Employee ID, Security Clearance Level).

Важно: Настройка Claims Mapping / Attribute Mapping на стороне IdP определяет, какие именно данные «попадают» в конкретное приложение (принцип минимальных привилегий / Data Minimization).

Сессии и Токены

• Сессия IdP (SSO Session): Создается после успешного логина. Обеспечивает Silent Auth (автоматический вход) в другие SP без повторного ввода пароля. Жизненный цикл управляется политиками IdP (Session Lifetime, Idle Timeout, Persistent Session / «Remember Me»).
• Сессия SP (Local Session): Создается в самом приложении после валидации токена. Может жить дольше или короче сессии IdP.
• Access Tokens / Refresh Tokens: «Попадают» в клиентские приложения (SPA, Mobile) для доступа к API.

Сценарии попадания в SSO: Как это выглядит на практике

SP-Initiated Flow (Инициатива со стороны сервиса)

Классический сценарий, описанный в вашем источнике (LinkedIn -> Google):

1. Пользователь заходит на sp.example.com.
2. SP видит отсутствие локальной сессии -> Редиректит на IdP с AuthnRequest (SAML) или Authorization Request (OIDC).
3. IdP проверяет свою сессию (SSO Cookie).
4. Если сессия есть: IdP сразу выдает токен/ассершн -> Пользователь в SP;
5. Если сессии нет: IdP показывает форму логина (Username/Password + MFA) -> Создает сессию IdP -> Выдает токен -> Пользователь в SP.

IdP-Initiated Flow (Инициатива со стороны провайдера идентичности)

Пользователь заходит на портал IdP (MyApps, Okta Dashboard, Microsoft My Account), видит каталог приложений («Kafelki»), кликает на иконку -> IdP генерирует ассершн/токен и POST-ит его в SP. Пользователь попадает сразу внутрь приложения.

Just-In-Time (JIT) Provisioning / SCIM

Когда пользователь впервые попадает в SSO в конкретное приложение:

• JIT Provisioning (SAML/OIDC): При первом логине SP создает локального пользователя на основе атрибутов из токена IdP.
• SCIM (System for Cross-domain Identity Management): IdP проактивно пушит создание/обновление/деактивацию пользователей в SP через REST API. Это лучший практик для управления жизненным циклом (Joiner/Mover/Leaver).

Кто НЕ попадает в SSO (Исключения и «Теневой ИТ»)

Понимание границ так же важно, как и понимание ядра.

• Локальные админские аккаунты (Break-glass accounts): Учетные записи для аварийного входа, если IdP недоступен. Хранятся в сейфе (PAM) или в самом приложении (Local DB).
• Legacy-приложения без поддержки протоколов: Старые thick-клиенты, мейнфреймы, оборудование (принтеры, свитчи, IPMI/BMC), не умеющие SAML/OIDC. Решается через Application Proxy, Identity-Aware Proxy (IAP) или парольные менеджеры (Enterprise Password Vaults).
• Отдельные среды (Dev/Test/Staging): Часто намеренно исключаются из корпоративного SSO для изоляции или используют отдельные IdP (тенанты).
• Shadow IT: Сервисы, заведенные сотрудниками корпоративной почтой без ведома ИТ. Они формально могут поддерживать «Login with Google/Microsoft», но не управляются централизованно (нет Conditional Access, нет логов, нет Lifecycle Management).

Политики, определяющие «Кто попадает» (Conditional Access / Access Policies)

Попадание в SSO — это не бинарное «да/нет», а результат оценки политик в реальном времени (Real-time Policy Evaluation).

IdP принимает решение на основе сигналов:

• Кто: Группа пользователя, роль, риск аккаунта (Identity Protection).
• Что: Приложение (SP), чувствительность данных (High Business Impact).
• Где: Геолокация, IP-репутация, Trusted Locations (Corporate Network vs Public WiFi).
• Как: Устройство (Managed/Compliant via MDM/Intune vs Unmanaged/BYOD), браузер, ОС.
• Когда: Время суток, нетипичные часы активности.

Результат оценки:

1. Allow (Seamless): Пускает молча (есть валидная сессия IdP + Compliant Device).
2. Allow with MFA (Step-up): Требует второй фактор (Push, FIDO2, OTP).
3. Allow Limited (Session Controls): Пускает, но с ограничениями (Read-only, блок скачивания, watermarking — через Conditional Access App Control / Reverse Proxy).
4. Block: Отказ в доступе (High Risk, Blocked Country, Non-compliant Device).

Жизненный цикл идентичности в SSO (Identity Lifecycle)

«Попадание в SSO» — это процесс, а не событие.

Лучшие практики: Как правильно определить круг лиц в SSO

Принцип «Zero Trust» — Никогда не доверяй, всегда проверяй

SSO не означает «один раз вошел — ходи везде вечно». Современный SSO = Continuous Access Evaluation (CAE). Токены короткоживущие (Access Token ~1h), Refresh Token ротируются, сессии IdP перепроверяются при каждом новом запросе к SP.

Единый каталог (Single Source of Truth)

Все идентичности (сотрудники, партнеры, боты) должны иметь запись в центральном IdP. Никаких локальных БД пользователей в приложениях.

Разделение тенантов (Multi-tenancy)

• Workforce Tenant: Для сотрудников (Entra ID, Okta Workforce).
• CIAM Tenant: Для клиентов (Auth0, Azure AD B2C, Keycloak, PingOne).
• B2B Federation: Партнеры логинятся через свой IdP (Home Realm Discovery), не создавая учетки в вашем каталоге.

Мониторинг и Аудит «Кто попал»

Обязательно логировать в SIEM:

• Успешные/неуспешные логины (Sign-in Logs).
• События MFA (Registration, Challenge, Success/Failure).
• Изменения политик Conditional Access.
• Провisioning/Deprovisioning события (SCIM Audit).
• Consent Grants (согласия пользователей на доступ приложений к их данным);

Резюме: Чек-лист «Попадания в SSO»

Сущность (пользователь, приложение, устройство) считается «попавшей в SSO», если выполнены ВСЕ условия:

1. Идентичность централизована: Есть запись в авторитетном IdP.
2. Протокол федерации: Приложение (SP) настроено на доверие к этому IdP (SAML/OIDC/WS-Fed).
3. Доверие установлено: Обмен метаданными (Metadata Exchange), сертификатами подписи/шифрования, настройка Audience/Client ID.
4. Атрибуты смэппены: IdP отдает нужные клеймы, SP их понимает и использует для авторизации.
5. Жизненный цикл автоматизирован: Joiner/Mover/Leaver работают через SCIM или JIT.
6. Политики применены: Conditional Access / Access Policies привязаны к приложению и группам пользователей.
7. Аудит включен: Логи уходят в SIEM / Log Analytics.

Ответ на вопрос «Кто попадает в SSO» многогранен. Это не просто список сотрудников. Это матрица пересечений: Субъекты (Люди, Боты, Партнеры, Клиенты) × Объекты (SaaS, On-prem, API, Инфраструктура) × Политики (Устройство, Локация, Риск, Роль).

Грамотное построение SSO, это не разовая настройка «галочки» в админке, а непрерывный процесс управления идентичностями (IGA), привилегированным доступом (PAM) и адаптивной безопасностью (Adaptive MFA / CAE). Только при таком подходе SSO перестает быть просто «удобством» и становится фундаментом киберустойчивости организации.

Статья подготовлена на основе актуальных стандартов (SAML 2.0, OIDC 1.0, OAuth 2.1, SCIM 2.0) и практик Zero Trust Architecture. Данные актуальны на .