SSO против SAML: объяснение для всех

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

Что такое SSO?#

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

Есть различные сценарии, когда применяется SSO.

Социальный SSO#

Иногда люди называют социальный вход социальным SSO. Например, пользователи могут использовать вход через Google, чтобы создать аккаунт в новом приложении, напрямую используя идентификацию и информацию, хранящуюся в Google. В этом сценарии пользователь управляет своей собственной идентификацией.

Социальный SSO упрощает пользователям управление их информацией, сокращая утомительные шаги в процессе создания аккаунта и входа. Социальный SSO обычно полагается на открытые стандарты протоколов, такие как OAuth 2.0 и OIDC.

Корпоративный SSO#

Сначала давайте разберем понятия поставщика идентичности и поставщика услуг простыми словами.

1. Поставщик идентичности (IdP) — это как "дозорный" вашей идентичности. Это система, которая хранит вашу информацию для входа и проверяет, кто вы есть. Представьте его как доверенный орган, который говорит: «Да, это человек, которым он утверждает быть». Примеры включают Google Workspace, Microsoft Entra и Okta Workforce Identity.
2. Поставщик услуг (SP) — это "приложение" или "сервис", к которому вы хотите получить доступ после подтверждения вашей идентичности. Это место, куда вы пытаетесь войти, например, приложение или веб-сайт. Например, Zoom, Slack или внутренние инструменты вашей компании — это все поставщики услуг.

Говоря простыми словами, поставщик идентичности подтверждает, кто вы, а поставщик услуг предоставляет вам доступ к своим услугам после подтверждения вашей идентичности.

Корпоративный SSO используется в более ориентированных на бизнес сценариях, и в зависимости от двух объясненных выше терминов, есть два типичных случая: SSO с инициированным IdP и SSO с инициированным SP. Хотя термины могут звучать технически, сценарии на самом деле довольно просты.

SSO с инициированным IdP#

Подумайте о том, когда вы, как сотрудник, получаете доступ к приложениям и ресурсам вашей компании. Обычно HR создаст для вас аккаунт. Затем вы используете этот аккаунт, чтобы войти в платформу, такую как Okta или Google Workspace. После входа вы будете направлены на корпоративный портал, где сможете получить доступ ко всем приложениям компании, таким как системы заработной платы, инструменты для сотрудничества, Workday и другие.

SSO с инициированным SP#

Теперь давайте рассмотрим это с другой стороны. Иногда вам нужно начать с определенной страницы входа продукта. Например, если вы хотите использовать Zoom для онлайн-встречи с вашими коллегами, вы увидите опцию "Войти через SSO". Этот сценарий известен как SSO с инициированным SP.

Какие проблемы решает корпоративный SSO#

Первое преимущество корпоративного SSO заключается в том, что он позволяет бизнесу управлять идентичностями работников легко, гибко и безопасно.

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

С другой стороны, в сценарии, как в случае SSO с инициированным SP, сотрудники получают доступ к нескольким приложениям и сервисам, принадлежащим компании. Когда сотрудники приходят или покидают компанию, HR должен создавать и удалять многочисленные аккаунты на всех продуктах и услугах компании, что утомительно и требует много времени.

Корпоративный SSO упрощает этот процесс через универсальную систему идентичности, а инструменты, такие как SCIM (Система управления кросс-доменной идентичностью) и Just-in-Time провизион, делают его еще более эффективным.

Для SSO с инициированным IdP это выгодно для строителей продуктов, которые хотят быть "готовыми к корпоративному использованию". Например, если вы стартап, который изначально ориентируется на индивидуальных потребителей, а позже крупная компания хочет использовать ваш продукт, они могут потребовать, чтобы сотрудники входили через Microsoft Entra, например. В этом случае вам нужно будет интегрировать корпоративный SSO в ваш продукт, чтобы заключить сделку.

Что такое SAML?#

SAML (Язык разметки утверждений безопасности) — это открытый стандартный протокол, используемый для аутентификации и авторизации. Наряду с OAuth и OIDC, SAML широко используется в системах управления идентичностью, особенно в управлении идентичностью рабочих. Коммерческие поставщики идентичности, такие как Okta и Microsoft Entra, обычно поддерживают SAML как один из их стандартных протоколов.

Некоторые старые системы и провайдеры социального входа также предлагают поддержку SAML, поэтому наличие SAML в вашей системе может помочь обеспечить совместимость с более широким спектром поставщиков идентичности и будущим ростом экосистемы.

Когда нужен SAML?#

SAML часто используется в сценариях корпоративного SSO. Например, рассмотрите такую ситуацию:

Ваша команда продаж обращается к разработчикам продукта и говорит: "У нас большой клиент, и они требуют вход через SAML. Нам нужно поддерживать эту технологию".

Для инженеров, которые не знакомы с SAML или IAM (Управление идентификацией и доступом), их первый шаг, вероятно, будет заключаться в поиске "SAML" или "входа через SAML".

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

Как работает SAML#

Вот упрощенное объяснение двух типов:

Поток с инициированием от SP#

1. Пользователь пытается получить доступ к ресурсу SP.
2. SP перенаправляет пользователя на IdP с запросом аутентификации SAML.
3. Пользователь входит в систему на IdP и проходит аутентификацию.
4. IdP генерирует утверждение SAML с идентичностью пользователя и, возможно, данными авторизации.
5. IdP отправляет утверждение SAML обратно SP, обычно через браузер пользователя.
6. SP обрабатывает утверждение, проверяет его и предоставляет/отказывает доступ пользователю.

Поток с инициированием от IdP#

1. Пользователь уже вошел на IdP и выбирает сервис/ресурс из портала IdP.
2. IdP генерирует утверждение SAML на основе текущей сессии пользователя, содержимое идентичность и атрибуты.
3. IdP отправляет утверждение непосредственно SP, без предварительного запроса от SP.
4. SP обрабатывает утверждение, проверяет его целостность и извлекает идентичность и атрибуты пользователя.
5. SP предоставляет или отказывает доступ на основе утверждения.

Чтобы увидеть, как работает SAML с технической точки зрения, ознакомьтесь с Как работает SAML

Разница между SAML и SSO#

Определения SAML и SSO часто путаются, но вот простое объяснение:

1. SSO — это процесс аутентификации, используемый приложениями и программным обеспечением, позволяющий пользователям войти один раз и получить доступ к нескольким службам.
2. SAML — это технический протокол, в основном используемый в управлении корпоративной идентичностью для безопасного обмена данными аутентификации.

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

Но как работает SSO?

Здесь в игру вступает SAML (Язык разметки утверждений безопасности). Думайте о SAML как о надежном посланнике между вашей системой входа (называемой поставщиком идентичности, или IdP) и приложениями, которые вы хотите использовать (называемыми поставщиками услуг, или SPs). Когда вы входите через SSO, SAML надежно отправляет "доказательство" вашей идентичности от IdP к приложению, подтверждая, что вы тот, кем утверждаете быть.

Так что, вкратце:

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

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

Использует ли корпоративный SSO другие протоколы?#

Да, помимо SAML, OIDC — это еще один протокол, который часто используется в сценариях корпоративного SSO. Например, в корпоративном коннекторе Logto поддерживаются как Microsoft Entra (OIDC), так и Microsoft Entra (SAML).

Стоит ли использовать SAML SSO?#

Если вы продаете корпоративным клиентам, важно рассмотреть возможность поддержки SAML как можно раньше. Но не сосредотачивайтесь только на поддержке протокола SAML — подумайте о всей аутентификационной цепочке корпоративного SSO. Вот несколько ключевых сценариев, которые стоит рассмотреть:

1. Разрешите вашим клиентам самостоятельно регистрироваться и настраивать корпоративный SSO.
2. Убедитесь, что сотрудники автоматически присоединяются к правильным организациям в многопользовательских приложениях (это можно сделать с помощью Just-in-Time провизионирования и SCIM).
3. Реализуйте энд-то-энд цепочку входа, совместимую с вашим ориентированным на потребителя процессом входа.

Реализуйте SAML и корпоративный SSO с помощью Logto#

Logto предоставляет энд-то-энд цепочки корпоративного SSO и поддерживает множество известных коннекторов SAML. Он может быть интегрирован во многие общие сценарии, которые вам понадобятся. Исследуйте все функции Logto, от Logto Cloud до Logto OSS, на веб-сайте Logto.