Single Sign-On (SSO) для системных аналитиков: от основ до деталей OIDC, SAML и Kerberos

Аннотация

Single Sign‑On (SSO) позволяет пользователям входить в разные приложения с одним набором учётных данных, упрощая доступ и повышая безопасность. Эта статья поможет системным аналитикам разобраться в принципах SSO, сравнить механизмы OpenID Connect (OIDC), SAML и Kerberos и выбрать подходящий для проекта. От простых объяснений до технических деталей — вы получите полное представление о том, как работает SSO.

1. Введение: Что такое SSO и почему это важно

Представьте, что вы приходите в офис, показываете пропуск на входе и получаете доступ ко всем кабинетам, лифтам и кофемашине без дополнительных проверок. Single Sign‑On (SSO), или единый вход, работает так же: пользователь один раз вводит логин и пароль (или использует другой способ аутентификации) и получает доступ ко всем нужным приложениям — от электронной почты до корпоративных порталов или облачных сервисов.

SSO решает несколько проблем:

• Удобство для пользователей: Не нужно запоминать десятки паролей или входить в каждое приложение отдельно.

• Снижение нагрузки на IT: Меньше запросов на сброс паролей и управление учётными записями.

• Повышение безопасности: Централизованное управление доступом снижает риск утечек паролей и упрощает внедрение двухфакторной аутентификации.

Где вы сталкиваетесь с SSO?

• В повседневной жизни: Вход через Google или Facebook в приложения вроде Trello, Spotify или YouTube. Один аккаунт открывает доступ к множеству сервисов.

• В работе: Корпоративный портал, где после одного входа вы работаете с CRM, почтой, системами учёта или внутренними базами данных.

• В технических системах: Интеграция облачных приложений (например, Salesforce) с корпоративной сетью, чтобы сотрудники не вводили пароли заново.

Как SSO работает на базовом уровне?

SSO полагается на сервер аутентификации, который мы называем Identity Provider (IdP). Это как охранник на входе в офис, который проверяет ваш пропуск. Приложения (например, веб-сайты или корпоративные системы) доверяют IdP, чтобы подтвердить, что вы — это вы. После проверки IdP выдаёт приложению "цифровой пропуск", который позволяет вам работать.

Механизмы SSO

Существует несколько способов реализовать SSO, и в этой статье мы разберём три популярных механизма:

• OpenID Connect (OIDC): Современный протокол для веб и мобильных приложений, например, вход через Google или Okta.

• SAML (Security Assertion Markup Language): Стандарт для корпоративных систем, часто используется с Active Directory или другими внутренними серверами.

• Kerberos: Быстрый и безопасный протокол для локальных сетей, особенно в средах Windows.

Каждый из них решает задачу SSO, но подходит для разных сценариев. Например, OIDC идеален для облачных приложений, SAML — для крупных организаций, а Kerberos — для внутренних сетей, где скорость важнее всего.

2. Как работает SSO: Общие этапы

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

Давайтеразберём процесс SSO на простых шагах. Эти этапы применимы к любому механизму SSO, будь то OIDC, SAML или Kerberos.

Этапы SSO

1. Пользователь хочет войти в приложение
   Вы открываете приложение, например, корпоративный портал или веб‑сайт вроде Trello, и нажимаете «Войти». Приложение понимает, что вы ещё не авторизованы (у вас нет «билета»), и решает отправить вас к тому, кто может это исправить.

2. Приложение отправляет вас на сервер аутентификации
   Приложение перенаправляет вас (через браузер или сеть) на сервер аутентификации, или Identity Provider (IdP). Это как охранник на входе в университет, который проверяет, кто вы. IdP может быть Google, корпоративный сервер или внутренняя система.

3. Вы доказываете, кто вы
   На IdP вы вводите логин и пароль, используете двухфакторную аутентификацию (например, код из SMS) или другой способ. Если вы уже вошли ранее (например, в почту Google), IdP может сразу узнать вас по «цифровому билету» и пропустить этот шаг.

4. IdP выдаёт приложению «билет»
   После проверки IdP отправляет приложению подтверждение, что вы — это вы. Этот «билет» содержит информацию о вас (например, имя или роль) и доказывает, что вы прошли проверку. Приложение получает его через ваш браузер или сеть.

5. Приложение пускает вас внутрь
   С «билетом» в руках приложение открывает вам доступ. Вы видите дашборд, можете редактировать документы или работать с данными. Приложение также решает, что вам разрешено делать (например, только читать или редактировать), на основе данных в «билете».

6. Вход в другие приложения без повторной проверки
   Если вы открываете другое приложение, использующее тот же IdP (например, второе приложение Google или другую корпоративную систему), IdP видит ваш существующий «билет» и сразу пускает вас. Вам не нужно заново вводить логин и пароль — это и есть магия SSO.

7. Выход из системы
   Когда вы заканчиваете работу, вы нажимаете «Выйти». Приложение удаляет ваш «билет», и доступ к нему закрывается. В некоторых случаях IdP также уничтожает ваш глобальный «билет», чтобы вы вышли из всех приложений, где использовали SSO.

Простая схема потока SSO

Почему это важно для аналитиков?

Как системный аналитик, вы будете проектировать системы с SSO, чтобы упростить жизнь пользователям и повысить безопасность. Понимание этих этапов поможет вам:

• Определить, какие приложения нужно интегрировать.

• Выбрать подходящий сервер аутентификации (IdP).

• Решить, какой механизм SSO использовать.

Что дальше?

Теперь, когда вы знаете, как SSO работает в общих чертах, мы сравним три популярных механизма — OpenID Connect, SAML и Kerberos — на этих же этапах, но в упрощённой форме. Это поможет понять, чем они отличаются и где их применять. А затем мы разберём каждый этап в деталях с техническими примерами, чтобы вы могли применить знания в реальных проектах.

3. Механизмы SSO: OIDC, SAML и Kerberos - упрощённое сравнение

Теперь, когда вы знаете, как работает SSO, давайте сравним три популярных механизма, которые его реализуют: OpenID Connect (OIDC), SAML и Kerberos. Каждый из них — как разный тип "студенческого билета" из нашей аналогии: они открывают двери, но по-разному. Мы пройдёмся по этапам SSO из предыдущего раздела и посмотрим, как каждый механизм справляется с задачей. Это поможет понять, где и когда их использовать.

Что такое OIDC, SAML и Kerberos?

• OpenID Connect (OIDC): Современный способ для веб и мобильных приложений. Используется, например, когда вы входите в Trello через Google. Работает через интернет, отправляя простые сообщения в формате JSON.

• SAML (Security Assertion Markup Language): Стандарт для корпоративных систем, таких как порталы банков или университетов. Используется в веб-приложениях и отправляет данные в формате XML, который сложнее, но надёжен.

• Kerberos: Быстрый и безопасный способ для локальных сетей, особенно в компаниях с Windows. Работает внутри сети, выдавая "билеты" для доступа к серверам, без браузера.

Сравнение механизмов по этапам SSO

Мы возьмём те же этапы SSO и посмотрим, как OIDC, SAML и Kerberos их выполняют. Для простоты представим, что пользователь хочет войти в приложение (например, веб-сайт или корпоративный сервер).

1. Пользователь хочет войти в приложение

• OIDC: Вы нажимаете "Войти через Google" на сайте, например, Trello. Сайт готовит сообщение с просьбой проверить вас и отправляет его Google.

• SAML: Вы нажимаете "Войти" на корпоративном портале. Портал создаёт запрос в виде письма (на "языке" XML) и отправляет его на сервер компании, например, Active Directory.

• Kerberos: Вы открываете приложение в корпоративной сети (например, общий диск). Ваш компьютер автоматически запрашивает "билет" у сервера сети (Key Distribution Center, KDC), без вашего участия.

Различие: OIDC и SAML работают через браузер и требуют, чтобы вы нажали "Войти". Kerberos часто незаметен, так как использует ваш вход в Windows.

2. Приложение отправляет вас на сервер аутентификации

• OIDC: Ваш браузер перенаправляется на сайт Google, где вы видите страницу входа (если ещё не вошли).

• SAML: Ваш браузер перенаправляется на корпоративный сервер, где появляется страница для ввода логина и пароля (если вы не вошли).

• Kerberos: Ваш компьютер сам связывается с KDC внутри сети, без браузера. Вы ничего не видите, если уже вошли в Windows.

Различие: OIDC и SAML используют браузер для связи с сервером аутентификации, что удобно для интернета. Kerberos работает напрямую в сети, что быстрее, но ограничено локальной средой.

3. Вы доказываете, кто вы

• OIDC: Вы вводите логин и пароль на странице Google или выбираете аккаунт, если уже вошли. Может быть двухфакторная аутентификация (например, код из SMS).

• SAML: Вы вводите корпоративный логин и пароль на странице сервера (например, Active Directory). Иногда используется карта доступа или другой метод.

• Kerberos: Ваш компьютер доказывает вашу личность через данные вашего входа в Windows. Вы не вводите ничего, если уже в сети.

Различие: OIDC и SAML часто требуют ввода данных, особенно если вы не вошли. Kerberos автоматичен, но работает только в доверенной сети.

4. Сервер выдаёт приложению "билет"

• OIDC: Google отправляет приложению код (как временный пропуск), который оно обменивает на "билет" с вашими данными (например, имя, email).

• SAML: Корпоративный сервер отправляет приложению письмо (XML) с вашими данными (например, имя, роль в компании).

• Kerberos: KDC выдаёт вашему компьютеру "билет" (Service Ticket), который приложение проверяет, чтобы пустить вас.

Различие: OIDC использует двухэтапный процесс (код, затем "билет"). SAML и Kerberos сразу дают полный "билет", но SAML — через браузер, а Kerberos — через сеть.

5. Приложение пускает вас внутрь

• OIDC: Приложение проверяет "билет" от Google и открывает вам доступ, например, к дашборду Trello. Оно знает ваше имя и, возможно, роль (например, "редактор").

• SAML: Приложение проверяет письмо от сервера и даёт доступ, например, к корпоративному порталу. Оно знает вашу роль (например, "администратор").

• Kerberos: Приложение проверяет "билет" от KDC и открывает доступ, например, к файлам на сервере. Ролей обычно нет, только доступ.

Различие: OIDC и SAML часто передают дополнительные данные (имя, роли), что удобно для сложных приложений. Kerberos даёт только доступ, без лишних деталей.

6. Вход в другие приложения без повторной проверки

• OIDC: Вы открываете другое приложение (например, YouTube) и входите через Google без пароля, потому что Google помнит ваш "билет".

• SAML: Вы открываете другую корпоративную систему (например, CRM) и входите без пароля, так как сервер помнит вас.

• Kerberos: Вы открываете другое приложение в сети (например, почту) и получаете доступ, так как KDC выдаёт новый "билет" автоматически.

Различие: Все три механизма поддерживают SSO, но OIDC и SAML делают это через браузер, а Kerberos — через сеть, что быстрее в локальной среде.

7. Выход из системы

• OIDC: Вы нажимаете "Выйти" в приложении, и оно забывает вас. Иногда оно просит Google тоже вас "забыть", но это не всегда.

• SAML: Вы нажимаете "Выйти", и приложение забывает вас. Часто оно говорит серверу завершить доступ ко всем системам (глобальный выход).

• Kerberos: Ваши "билеты" истекают (обычно через несколько часов), или вы выходите из Windows, завершая доступ.

Различие: SAML лучше справляется с глобальным выходом (из всех приложений). OIDC это делает реже, а Kerberos полагается на время действия "билетов".

Таблица сравнения

Когда что выбрать?

• OIDC: Если вы работаете с веб-сайтами, мобильными приложениями или облачными сервисами (например, SaaS). Прост в настройке и популярен.

• SAML: Если у вас корпоративная система с интеграцией в Active Directory или другими серверами. Надёжен, но сложнее.

• Kerberos: Если вы в локальной сети (например, офис с Windows), где важна скорость и безопасность.

Что дальше?

Теперь вы знаете, как OIDC, SAML и Kerberos справляются с SSO на базовом уровне. В следующем разделе мы разберём эти же этапы в деталях, с техническими примерами, кодом и схемами, чтобы вы могли применить знания в проектах. Мы покажем, как формируются запросы, как обрабатываются "билеты" и как настроить каждый механизм.

4. Детальный разбор этапов SSO для OIDC, SAML и Kerberos

Теперь, когда вы понимаете основы SSO и различия между OpenID Connect (OIDC), SAML и Kerberos на простом уровне, пора углубиться в технические детали. В этом разделе мы разберём каждый этап SSO, сравнивая, как OIDC, SAML и Kerberos реализуют его, с примерами кода, псевдокодом и текстовыми схемами. Это поможет системным аналитикам проектировать системы с SSO, выбирать подходящий протокол и документировать процессы.

Мы будем использовать те же семь этапов SSO, но теперь с фокусом на технические аспекты, такие как форматы данных, протоколы передачи и проверки. Для OIDC рассмотрим Authorization Code Flow, для SAML — SP-Initiated SSO, а для Kerberos — аутентификацию в домене Windows. Каждый этап включает примеры, чтобы вы могли увидеть, как это работает на практике.

Этапы SSO: Технический разбор

1. Пользователь запрашивает доступ к приложению

OIDC:

• Пользователь открывает веб-приложение (Relying Party, RP), например, https://app.example.com ^[1], и нажимает "Войти через Google".

• RP формирует запрос авторизации для IdP (например, Google) в виде URL, отправляемого на Authorization Endpoint (https://accounts.google.com/o/oauth2/v2/auth ^[2]).

• Параметры запроса:

  • client_id: Идентификатор приложения (например, 12345.apps.googleusercontent.com ^[3]).

  • redirect_uri: Адрес для ответа (например, https://app.example.com/callback ^[4]).

  • scope: Запрашиваемые данные (например, openid profile email).

  • response_type: code (для Authorization Code Flow).

  • state: Защита от CSRF (например, xyz789).

• Пример запроса:

  https://accounts.google.com/o/oauth2/v2/auth?client_id=12345.apps.googleusercontent.com&redirect_uri=https://app.example.com/callback&scope=openid%20profile%20email&response_type=code&state=xyz789

• RP отправляет HTTP-редирект (GET), и браузер перенаправляется на IdP.

SAML:

• Пользователь открывает приложение (Service Provider, SP), например, https://portal.company.com ^[5], и нажимает "Войти".

• SP создаёт SAML AuthnRequest (XML) для IdP (например, ADFS) и отправляет его на Single Sign-On Service (https://idp.company.com/sso ^[6]).

• Элементы AuthnRequest:

  • ID: Уникальный идентификатор (например, _a12345).

  • Issuer: Идентификатор SP (например, https://portal.company.com/metadata ^[7]).

  • AssertionConsumerServiceURL: Адрес для ответа (например, https://portal.company.com/saml/acs ^[8]).

• Пример AuthnRequest (упрощённый):

  <samlp:AuthnRequest ID="_a12345" Version="2.0" IssueInstant="2025-06-28T15:34:00Z" Destination="https://idp.company.com/sso" AssertionConsumerServiceURL="https://portal.company.com/saml/acs">
    <saml:Issuer>https://portal.company.com/metadata</saml:Issuer>
  </samlp:AuthnRequest>
  

• SP отправляет XML через HTTP POST (HTML-форма) или Redirect (сжатый Base64 в URL), и браузер перенаправляется на IdP.

Kerberos:

• Пользователь открывает приложение в локальной сети (например, общий диск на fileserver.company ^[9].local), используя компьютер, вошедший в домен Windows.

• Клиент (компьютер пользователя) автоматически запрашивает доступ у Key Distribution Center (KDC), который выступает как IdP в домене.

• Процесс начинается с получения Ticket Granting Ticket (TGT), если его ещё нет. TGT — это "пропуск", подтверждающий, что пользователь уже аутентифицирован в домене.

  Client → KDC: Request TGT for user@company.local

• Запрос отправляется по сети (обычно через протокол Kerberos over TCP/UDP), без участия браузера.

Сравнение:

• Формат: OIDC использует URL (JSON-подобный), SAML — XML, Kerberos — бинарные сообщения.

• Передача: OIDC и SAML работают через браузер (HTTP GET/POST). Kerberos — через сеть, что быстрее, но ограничено доменом.

• Автоматизация: OIDC и SAML требуют действия пользователя ("Войти"). Kerberos автоматичен, если пользователь вошёл в домен.

---

2. Аутентификация на IdP

OIDC:

• IdP (Google) получает URL-запрос и проверяет параметры (client_id, redirect_uri).

• Если пользователь не аутентифицирован, IdP показывает страницу входа:

  • Пользователь вводит логин/пароль или использует MFA (например, код из SMS).

  • Если сессия активна (например, от Gmail), IdP пропускает вход.

• IdP проверяет учётные данные через свою базу (или внешний сервис) и создаёт сессию (cookie в браузере).

SAML:

• IdP (ADFS) получает SAML AuthnRequest, декодирует XML и проверяет Issuer.

• Если пользователь не аутентифицирован, IdP показывает страницу входа:

  • Пользователь вводит корпоративный логин/пароль или использует методы, такие как Kerberos (встроенный в Windows) или смарт-карты.

  • Если сессия активна, IdP пропускает вход.

• IdP проверяет данные через Active Directory или LDAP и создаёт сессию (cookie или серверная).

Kerberos:

• KDC получает запрос на TGT от клиента (компьютера пользователя).

• Если TGT отсутствует, KDC проверяет учётные данные пользователя:

  • Использует пароль пользователя (или его хэш), хранимый в Active Directory.

  • Аутентификация автоматическая, если пользователь вошёл в Windows.

• KDC выдаёт TGT, зашифрованный с ключом пользователя, и клиент сохраняет его в кэше.

• Псевдокод:

  KDC → Client: TGT encrypted with user_key
  

Сравнение:

• Методы: OIDC поддерживает потребительские методы (пароль, MFA). SAML — корпоративные (Kerberos, LDAP). Kerberos использует сетевые ключи, автоматичен.

• Сессия: OIDC и SAML создают браузерную сессию (cookie). Kerberos выдаёт TGT, хранимый на клиенте.

• Контекст: OIDC и SAML для интернета, Kerberos — для локальной сети.

---

3. Формирование ответа IdP

OIDC:

• IdP (Google) создаёт Authorization Code (например, abc123) и готовит ID Token/Access Token для последующего обмена.

• Ответ — URL с code и state для redirect_uri:

  https://app.example.com/callback?code=abc123&state=xyz789
  

• IdP отправляет HTTP-редирект через браузер.

SAML:

• IdP (ADFS) создаёт SAML Assertion (XML) с данными:

  • NameID (например, user@company.com ^[10]).

  • Атрибуты (например, role=admin).

• Assertion оборачивается в SAML Response, подписывается и отправляется через HTTP POST:

  <samlp:Response ID="_c98765" Destination="https://portal.company.com/saml/acs">
    <saml:Assertion ID="_b67890">
      <saml:Subject>
        <saml:NameID>user@company.com</saml:NameID>
      </saml:Subject>
      <saml:AttributeStatement>
        <saml:Attribute Name="role" Value="admin"/>
      </saml:AttributeStatement>
    </saml:Assertion>
  </samlp:Response>
  

• Форма для POST:

  <form method="POST" action="https://portal.company.com/saml/acs">
    <input type="hidden" name="SAMLResponse" value="base64-encoded-xml" />
    <input type="hidden" name="RelayState" value="xyz789" />
  </form>
  

Kerberos:

• KDC выдаёт Service Ticket для запрошенного приложения (например, fileserver.company ^[9].local), используя TGT.

• Service Ticket зашифрован с ключом сервера и содержит данные пользователя.

• Псевдокод:

  Client → KDC: Request Service Ticket with TGT
  KDC → Client: Service Ticket encrypted with server_key
  

Сравнение:

• Формат: OIDC — URL с кодом, SAML — XML, Kerberos — бинарный билет.

• Передача: OIDC и SAML — через браузер, Kerberos — через сеть.

• Содержимое: OIDC откладывает данные, SAML передаёт всё, Kerberos — только доступ.

---

4. Обработка ответа приложением

OIDC:

• RP получает URL с code и state, проверяет state.

• Отправляет серверный запрос на Token Endpoint:

  POST /o/oauth2/v2/token HTTP/1.1
  Host: accounts.google.com
  code=abc123&client_id=12345.apps.googleusercontent.com&client_secret=secret123&redirect_uri=https://app.example.com/callback&grant_type=authorization_code
  

• Получает ID Token (JWT) и Access Token:

  {
    "id_token": "eyJhbGciOiJSUzI1NiIs...",
    "access_token": "ya29.a0AfH6S...",
    "refresh_token": "1//04T..."
  }
  

• Проверяет подпись ID Token и создаёт сессию.

SAML:

• SP получает SAML Response, проверяет подпись и метаданные.

• Извлекает NameID и атрибуты, создаёт сессию:

  {
    "user_id": "user@company.com",
    "role": "admin"
  }
  

Kerberos:

• Клиент отправляет Service Ticket приложению (серверу).

• Сервер расшифровывает билет, подтверждает доступ и создаёт сессию.

• Псевдокод:

  Client → Server: Service Ticket
  Server: Decrypt ticket, grant access
  

Сравнение:

• Обработка: OIDC требует серверного запроса, SAML — проверки XML, Kerberos — проверки билета.

• Сложность: OIDC проще (JSON), SAML сложнее (XML), Kerberos сложен из-за шифрования.

• Данные: OIDC и SAML передают атрибуты, Kerberos — только идентификатор.

---

5. Авторизация (доступ к ресурсам)

OIDC:

• RP использует ID Token (role=editor) для локального доступа и Access Token для API:

  GET /userinfo HTTP/1.1
  Host: oauth2.googleapis.com
  Authorization: Bearer ya29.a0AfH6S...
  

SAML:

• SP использует атрибуты (role=admin) для доступа к ресурсам (например, админ-панель).

Kerberos:

• Сервер предоставляет доступ (например, к файлам) на основе Service Ticket, без дополнительных атрибутов.

Сравнение:

• Гибкость: OIDC поддерживает API, SAML — статичные атрибуты, Kerberos — базовый доступ.

• Контекст: OIDC для веб/API, SAML для порталов, Kerberos для сетевых ресурсов.

---

6. SSO

OIDC:

• Второе приложение запрашивает код, IdP использует сессию и выдаёт новый код.SAML:

• Второе приложение запрашивает Assertion, IdP выдаёт новый Response.Kerberos:

• Клиент запрашивает новый Service Ticket с TGT, KDC выдаёт его.

Сравнение:

• Механизм: OIDC и SAML — через браузер, Kerberos — через сеть.

• Скорость: Kerberos быстрее в сети, OIDC/SAML медленнее из-за HTTP.

---

7. Завершение сессии

OIDC:

• RP удаляет сессию, опционально отправляет запрос на End Session:

  https://accounts.google.com/o/oauth2/v2/logout?id_token_hint=eyJhbGciOiJSUzI1NiIs...&post_logout_redirect_uri=https://app.example.com/logout

SAML:

• SP инициирует SLO, отправляя LogoutRequest:

  <samlp:LogoutRequest ID="_e12345" Destination="https://idp.company.com/slo">
    <saml:NameID>user@company.com</saml:NameID>
  </samlp:LogoutRequest>

• IdP завершает все сессии.

Kerberos:

• TGT и Service Tickets истекают (например, через 10 часов).

  Client: Clear ticket cache

Сравнение:

• Глобальность: SAML SLO завершает все сессии, OIDC — опционально, Kerberos — по таймеру.

• Сложность: SAML сложнее, OIDC проще, Kerberos автоматичен.

---

Что дальше?

Этот раздел показал, как OIDC, SAML и Kerberos реализуют SSO на техническом уровне. В следующем разделе мы сравним их сценарии применения, преимущества и недостатки, чтобы вы могли выбрать подходящий протокол для вашего проекта.

5. Когда использовать OIDC, SAML или Kerberos

Теперь, когда мы разобрали, как OpenID Connect (OIDC), SAML и Kerberos реализуют Single Sign-On (SSO) на каждом этапе, пора ответить на главный вопрос системного аналитика: какой протокол выбрать для вашего проекта? Каждый из этих механизмов подходит для определённых сценариев, имеет свои сильные и слабые стороны, и выбор зависит от ваших требований: типа приложений, инфраструктуры и уровня безопасности. В этом разделе мы сравним сценарии применения, преимущества и недостатки OIDC, SAML и Kerberos, а также дадим рекомендации, как выбрать подходящий протокол.

Сценарии применения

• OpenID Connect (OIDC):

  • Когда использовать: Для современных веб-приложений, мобильных приложений и облачных сервисов (SaaS). Примеры: вход через Google в Trello, Spotify или Jira; интеграция с облачными IdP, такими как Okta или Auth0.

  • Сценарии: Потребительские приложения, где пользователи входят через социальные сети (Google, Facebook) или корпоративные облачные платформы. Подходит для проектов, где важна простота интеграции и поддержка API.

  • Пример: Вы разрабатываете SaaS-приложение, которое должно поддерживать вход через Google или Microsoft. Пользователи ожидают удобный интерфейс и возможность вызова API (например, для доступа к календарю).

• SAML (Security Assertion Markup Language):

  • Когда использовать: Для корпоративных веб-приложений, интегрированных с внутренними системами, такими как Active Directory или LDAP. Примеры: корпоративные порталы, ERP-системы, банки, университеты.

  • Сценарии: Организации, где нужно интегрировать несколько внутренних систем (CRM, HR-порталы) с централизованным сервером аутентификации (например, ADFS или Shibboleth). Подходит для сложных политик доступа с передачей множества атрибутов (роли, группы).

  • Пример: Вы настраиваете доступ к корпоративному порталу, который должен работать с Active Directory, передавая роли сотрудников (например, "администратор", "менеджер").

  • Уточнение: SAML IdP (например, ADFS) может использовать Kerberos для аутентификации пользователей в домене Windows, если они уже вошли в сеть. Это не часть SAML, а метод, который IdP применяет для проверки личности, что делает процесс прозрачным для пользователей в корпоративной сети.

• Kerberos:

  • Когда использовать: Для локальных сетей, особенно в средах Windows с Active Directory. Примеры: доступ к общим дискам, почтовым серверам (Exchange) или другим ресурсам в домене.

  • Сценарии: Корпоративные сети, где важна высокая производительность и безопасность без использования браузера. Подходит для внутренних приложений, где пользователи уже аутентифицированы в домене.

  • Пример: Вы проектируете доступ к файловому серверу в офисе, где сотрудники входят в свои компьютеры через учётные данные Windows.

Преимущества и недостатки

Рекомендации для системных аналитиков

1. Анализируйте требования проекта:

   • Тип приложений: Веб/мобильные → OIDC. Корпоративные веб-системы → SAML. Локальная сеть → Kerberos.

   • Инфраструктура: Есть ли Active Directory? Используются ли облачные IdP? Это определит выбор между SAML и OIDC.

   • API: Если нужны вызовы API (например, Google Calendar), выбирайте OIDC.

   • Безопасность: Для строгих корпоративных требований (банки, госучреждения) SAML или Kerberos предпочтительнее.

2. Оценивайте сложность внедрения:

   • OIDC проще всего интегрировать благодаря библиотекам (например, oidc-client) и поддержке облачных IdP.

   • SAML требует настройки метаданных и работы с XML, что сложнее, но оправдано для корпоративных систем.

   • Kerberos сложен вне Windows, но встроен в Active Directory, что упрощает внедрение в домене.

3. Учитывайте пользовательский опыт:

   • OIDC предлагает знакомый интерфейс (например, вход через Google) и удобен для пользователей.

   • SAML может быть менее интуитивным из-за корпоративных страниц входа.

   • Kerberos прозрачен, но ограничен внутренней сетью.

4. Чек-лист для выбора протокола:

   • Нужна ли поддержка мобильных приложений? → OIDC.

   • Есть ли интеграция с Active Directory? → SAML или Kerberos.

   • Требуется ли доступ к API? → OIDC.

   • Важен ли глобальный выход (Single Logout)? → SAML.

   • Работаете ли вы в локальной сети? → Kerberos.

Таблица сравнения: Как выбрать протокол

Пояснение: ✅ — отлично подходит, ⚠️ — ограниченно/возможно, ❌ — не подходит.

Что дальше?

Выбрав подходящий протокол, вы можете приступать к проектированию SSO. Используйте инструменты, такие как Keycloak (поддерживает OIDC и SAML), Okta или ADFS, и изучите их документацию. В следующем разделе мы подведём итог и дадим рекомендации, как документировать SSO для проекта, а также предложим ресурсы для дальнейшего изучения.

6. Заключение и рекомендации

Single Sign-On (SSO) — это мощный инструмент, который упрощает доступ к приложениям, повышает удобство для пользователей и укрепляет безопасность за счёт централизованного управления. В этой статье мы разобрали, как работает SSO, сравнили три популярных механизма — OpenID Connect (OIDC), SAML и Kerberos — на высоком уровне и в технических деталях. Каждый из них решает задачу SSO, но подходит для разных сценариев: OIDC для веб и мобильных приложений, SAML для корпоративных систем, а Kerberos для локальных сетей. Теперь, когда вы понимаете их различия, пора применить знания в ваших проектах.

Ключевые выводы

• SSO упрощает жизнь: Один вход открывает доступ ко множеству приложений, снижая нагрузку на пользователей и IT-команды.

• OIDC — для современных приложений: Простота JSON, поддержка API и интеграция с облачными IdP (Google, Okta) делают его идеальным для SaaS и мобильных приложений.

• SAML — для корпоративной среды: Надёжный, но сложный, он отлично подходит для интеграции с Active Directory и передачи сложных атрибутов, таких как роли.

• Kerberos — для локальных сетей: Быстрый и прозрачный в доменах Windows, но ограничен локальной инфраструктурой и не подходит для веб-приложений.

• Выбор зависит от контекста: Анализируйте тип приложений, инфраструктуру и требования безопасности, чтобы выбрать подходящий протокол.

Рекомендации для системных аналитиков

Как системный аналитик, вы играете ключевую роль в проектировании SSO. Вот практические советы, которые помогут вам внедрить SSO в проекте:

1. Начните с анализа требований:

   • Какие приложения нужно интегрировать? Веб, мобильные или локальные?

   • Есть ли существующая инфраструктура (например, Active Directory)?

   • Нужен ли доступ к API или сложные политики ролей?

   • Требуется ли глобальный выход (Single Logout)?

2. Выберите подходящий протокол:

   • Используйте OIDC для облачных и мобильных приложений, особенно если нужна интеграция с Google, Okta или Auth0.

   • Выбирайте SAML для корпоративных систем с Active Directory или Shibboleth, где важны атрибуты и надёжность.

   • Применяйте Kerberos в локальных сетях Windows, где нужна высокая производительность и прозрачная аутентификация.

3. Документируйте архитектуру SSO:

   • Опишите роли: Identity Provider (IdP), Service Provider (SP) или клиент.

   • Укажите протокол и его этапы (например, OIDC Authorization Code Flow).

   • Нарисуйте схемы потоков данных (например, перенаправления в OIDC/SAML или обмен билетами в Kerberos).

   • Определите требования к безопасности (HTTPS, подписи, шифрование).

4. Чек-лист для проектирования SSO:

   • Определены все приложения, участвующие в SSO.

   • Выбран IdP (например, Google, ADFS, Keycloak).

   • Указан протокол (OIDC, SAML, Kerberos) и обоснован выбор.

   • Настроены параметры (например, scope для OIDC, атрибуты для SAML).

   • Проверена поддержка Single Logout (SLO), если требуется.

   • Протестирована интеграция (например, через Keycloak или Okta).

   • Документированы ошибки и их обработка (например, неверный client_id).

5. Используйте инструменты:

   • Keycloak: Поддерживает OIDC и SAML, легко настраивается.

   • Okta или Auth0: Облачные IdP для OIDC и SAML.

   • Active Directory Federation Services (ADFS): Для SAML и Kerberos в Windows.

   • Shibboleth: Для SAML в академических или корпоративных средах.

6. Тестируйте и обучайте:

   • Протестируйте SSO на всех этапах: от входа до выхода.

   • Обучите команду, как обрабатывать ошибки (например, истёкший токен в OIDC или просроченный билет в Kerberos).

   • Убедитесь, что пользователи понимают процесс входа и выхода.

Ресурсы для дальнейшего изучения

• OIDC:

  • Спецификация: openid.net/specs/openid-connect-core-1_0.html ^[11]

  • Keycloak: keycloak.org/docs/latest/server_admin ^[12]

  • Okta Developer: developer.okta.com ^[13]

• SAML:

  • Спецификация: oasis-open.org/standards#samlv2.0 ^[14]

  • ADFS: learn.microsoft.com/en-us/windows-server/identity/ad-fs ^[15]

  • Shibboleth: shibboleth.net ^[16]

• Kerberos:

  • MIT Kerberos: web.mit.edu/kerberos ^[17]

  • Microsoft Kerberos: learn.microsoft.com/en-us/windows-server/security/kerberos ^[18]

Заключение

SSO — это не просто технология, а способ сделать системы удобными и безопасными. Понимая, как работают OIDC, SAML и Kerberos, вы сможете спроектировать архитектуру, которая отвечает потребностям пользователей и бизнеса. Начните с анализа требований, выберите подходящий протокол и протестируйте решение. В следующем разделе (приложения) мы добавим глоссарий терминов и примеры конфигураций, чтобы вы могли сразу применить знания.