SAML 2.0 на собеседовании системного аналитика

Зачем SAML в 2026

SAML 2.0 (Security Assertion Markup Language) — стандарт SSO в enterprise. Доминирует в банках, корпорациях, госкомпаниях. На SA-собесе в банке РФ обязательны вопросы про SAML — уровень концепций.

Главная боль без SAML — SA в банке пишет ТЗ «авторизация через корпоративный SSO», но не различает SAML от OIDC. Команда выбирает OIDC, корпоративный IdP не поддерживает — переделка на полтора месяца.

OIDC — современный стандарт, активно теснит SAML, но в enterprise SAML живёт и будет жить ещё годы.

Роли в SAML

• IdP (Identity Provider) — провайдер идентификации (Active Directory FS, Okta, Keycloak)
• SP (Service Provider) — приложение, которое делегирует authn к IdP
• User — конечный пользователь

[User] → [SP] → "redirected to" → [IdP]
                                      ↓
                                [User logs in]
                                      ↓
[User] ← [SP] ← "SAML response" ← [IdP]

Trust: SP и IdP обмениваются метаданными (XML-файлы) — содержат entity ID, endpoints, certificates. Этот обмен — ручная настройка между командами.

Authentication flow

SP-initiated SSO (стандарт):

1. User → SP: GET /private/page
2. SP видит, что нет сессии → генерирует AuthnRequest (XML), редиректит User на IdP
3. User → IdP: с AuthnRequest
4. IdP логинит user (если ещё не залогинен), формирует SAML Response с Assertion
5. IdP redirect → User → SP с SAML Response
6. SP проверяет подпись Response, извлекает атрибуты, создаёт session
7. User → SP: /private/page (теперь авторизован)

Bindings (как передаётся SAML):

• HTTP Redirect — через query string (для AuthnRequest)
• HTTP POST — через form (для SAML Response)
• Artifact — короткий идентификатор, SP делает back-channel запрос к IdP за полным response

IdP-initiated SSO: user сначала логинится в IdP (например, корпоративный портал), кликает на иконку приложения, IdP отправляет SAML Response в SP без AuthnRequest. Менее безопасно (нет state/relay state).

Assertion и подпись

SAML Assertion — XML-документ с информацией о пользователе:

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>user-12345@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>anna@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="department">
      <saml:AttributeValue>IT</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Подпись: XML Digital Signature через приватный ключ IdP. SP проверяет публичным ключом из metadata.

Проверки на стороне SP:

• Подпись валидна
• NotBefore ≤ now ≤ NotOnOrAfter
• Audience совпадает с entity ID SP
• InResponseTo совпадает с originally sent AuthnRequest ID

SAML vs OIDC

OIDC — современнее. Но в enterprise (банки, госы) SAML — стандарт de facto. Если выбор за нами и target — современный B2B/consumer — OIDC. Если интегрируемся с корпоративным AD FS / Okta SAML — SAML.

Что описать в ТЗ

Минимум для SAML-интеграции:

• IdP / SP — кто кто
• Bindings — Redirect / POST / Artifact
• AuthnRequest — kakие параметры, signed или нет
• Attribute Mapping — какие SAML-атрибуты → какие поля в нашей системе (email, role, department)
• Logout — Single Logout (SLO) поддерживается или нет
• Metadata exchange — кто отдаёт metadata кому, как обновляется при ротации сертификатов
• Сертификаты — algorithm (SHA-256), валидность, ротация

SAML Integration Spec:
  IdP: corp.example.com/adfs
  SP: app.example.com (entity_id: https://app.example.com/saml)
  Binding: HTTP-POST для Response, HTTP-Redirect для AuthnRequest
  NameID format: emailAddress
  Required attributes: email, full_name, department
  Optional: phone, manager_email
  Signature: SHA-256, certificate rotation на стороне IdP с уведомлением 30 дней
  SLO: поддерживается (через HTTP-Redirect)

Частые ошибки

Не проверять подпись. Самая частая security-уязвимость SAML. Проверять обязательно.

Не валидировать Audience. Без проверки SAML Response, выписанный для другого SP, проходит.

Игнорировать NotOnOrAfter. Старый Response можно переиспользовать (replay attack). Проверять время валидности.

Использовать SHA-1. Слабое — устарело. SHA-256 минимум.

SAML для мобильного приложения. SAML не предназначен для нативки. OIDC.

IdP-initiated SSO без RelayState. Уязвим к атакам на response-injection. По возможности — SP-initiated.

Не описывать ротацию сертификатов в ТЗ. Сертификат IdP кончится через 2 года → integration сломается. Процесс уведомления и обновления — обязателен в ТЗ.

Связанные темы

• OAuth на собесе SA
• JWT на собесе SA
• OWASP Top 10 на собесе SA
• RBAC vs ABAC на собесе SA
• Подготовка к собесу системного аналитика

FAQ

SAML мёртв?

В стартапах и consumer — почти. В enterprise (банки, корпорации, гос) — стандарт ещё на 5-10 лет. AD FS, Okta, корпоративные IdP по-прежнему SAML.

Можно ли использовать SAML и OIDC одновременно?

Да, многие IdP (Okta, Keycloak) поддерживают оба. Корпоративные пользователи через SAML, внешние partners через OIDC.

Что такое SCIM?

System for Cross-domain Identity Management — стандарт provisioning пользователей (создать/обновить/удалить аккаунт через API IdP). Работает рядом с SAML/OIDC: SAML для authn, SCIM для управления аккаунтами.

IdP должна знать о каждом SP?

Да. Метаданные SP регистрируются в IdP. На большом enterprise это catalog с десятками SP.

Что такое WS-Federation?

Альтернативный стандарт SSO от Microsoft. На практике вытеснен SAML и OIDC. Встречается в legacy AD FS-окружениях.

Это официальная информация?

Нет. Статья основана на спецификации SAML 2.0 (OASIS), документации AD FS / Okta / Keycloak и общей практике SSO в enterprise.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.