Узнайте о SSO, инициированном поставщиком услуг, для B2B-приложений

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

Концепция#

Начнем с опознавания ключевых элементов, которые следует понимать:

• Поставщик услуг (SP): Ваши приложения или сервисы, которые могут быть как одним приложением, так и несколькими, использующими единую систему идентификации.
• Корпоративный провайдер идентификации (IdP): Поставщик идентификации, на которого полагаются ваши корпоративные клиенты для управления идентификацией сотрудников и разрешениями для приложений. Они могут использовать разных поставщиков, таких как Okta, Azure AD, Google Workspace или даже собственные IdP.
• Организация поставщика услуг (SP Org): B2B-приложения часто поддерживают многопользовательскую архитектуру для разных клиентских организаций.
• Организация провайдера идентификации (IdP Org): IdP также поддерживают многопользовательскую архитектуру для различных клиентских организаций. Идеально, если одно предприятие может связать свою IdP Org с SP Org, синхронизируя идентификацию сотрудников, но на практике это может быть сложнее.
• Корпоративный учетный адрес: Обычно идентифицируется использованием корпоративного домена электронной почты для входа. Эти корпоративные почтовые аккаунты принадлежат компании.

Далее погрузимся в SSO и два ключевых протокола:

• Единый вход (SSO): SSO позволяет пользователям получать доступ к нескольким сервисам или приложениям, используя один набор учетных данных. Это упрощает управление доступом и повышает безопасность.
• Протоколы SAML и OIDC: SSO опирается на эти протоколы для аутентификации и авторизации, каждый из которых имеет свои преимущества и недостатки.

Существует два основных механизма запуска SSO:

• SSO, инициированное IdP: В SSO, инициированном IdP, провайдер идентификации (IdP) управляет процессом единого входа. Пользователи начинают аутентификацию через интерфейс IdP.
• SSO, инициированное SP: В SSO, инициированном SP, поставщик услуг (SP) берет на себя ведущую роль в инициации и управлении процессом единого входа, что часто предпочтительно в B2B-сценариях.

Теперь давайте подробнее рассмотрим SSO, инициированное SP.

Поверхностный уровень: пользовательский опыт#

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

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

1. Соответствие доменов электронной почты: Ассоциируйте домен электронной почты с конкретным соединителем IdP. Это влияет на пользователей с адресами электронной почты под этим доменом. Убедитесь в проверке владения доменом, чтобы предотвратить зловредные конфигурации.
2. Соответствие названий организаций: Свяжите название организации с соединителем IdP, полагаясь на то, что пользователи запомнят название своей организации.
3. Соответствие личным электронным адресам пользователя: Это позволяет вам напрямую определять, разрешен ли учетный адрес пользователя для SSO, не полагаясь на домены электронной почты или названия организаций. Вы можете добиться этого, приглашая пользователей вручную, настраивая правила необходимого SSO или автоматически синхронизируя их учетные записи через синхронизацию каталогов.

При проектировании домашней страницы входа существуют два типа форм, которые можно выбрать в зависимости от бизнес-модели вашего продукта:

1. B2B-продукты: Рекомендуется напрямую отображать кнопки SSO, чтобы упростить их использование для членов ваших корпоративных клиентов, которым необходимо использовать SSO.
2. Продукты, совместимые с B2C и B2B: Поскольку большинство пользователей не будут использовать SSO, оцените домены электронной почты, чтобы определить, требуется ли SSO. Вы можете отложить презентацию проверки учетных данных, скрыв ее изначально и показывая только после подтверждения идентичности пользователя.

Подлежащая сложность: модель пользовательской идентичности#

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

Отношения ключевых элементов редко бывают один-к-одному; вам следует рассмотреть сценарии один-ко-многим и даже много-ко-многим. Постепенно рассмотрим эти варианты:

• Одна IdP Org с несколькими доменами электронной почты: Если вы полагаетесь на домены электронной почты для определения идентичности пользователя, вам необходимо поддерживать привязку нескольких доменов.
• Один домен электронной почты, соответствующий нескольким IdP Org: Если домен может принадлежать нескольким IdP Org, пользователи должны выбирать IdP, который они хотят использовать для единого входа.
• Одна IdP Org, связанная с несколькими SP Org: Рассмотрите возможность предоставления быстрого подключения одной IdP к нескольким SP Org.
• Один пользовательский аккаунт в нескольких IdP Org и SP Org: Разные SP Org могут требовать проверки через разные IdP.

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

• Принятие решений при активации SSO: Необходимо принять решение, повлияет ли SSO только на определенные SP Org арендаторов или на все SP Org арендаторов. Первое предоставляет гибкость, тогда как второе соответствует тенденции к корпоративному управлению и контролю идентификации и доступа.
• Учет периода перехода: Как SP, вы должны учесть неопределенности со стороны третьих IdP сервисов. Администраторы компаний всегда должны иметь возможность получить доступ к вашему приложению через SSO или учетные данные, и члены корпоративных пользователей могут нуждаться в них в момент перехода.

Эти вопросы касаются различных сценариев; многие другие возможности и детали могут быть исследованы.

Заключение#

Надеемся, что наш анализ SSO, инициированного SP, предложит вам новые взгляды на решения в области корпоративной идентификации. Хорошая новость заключается в том, что Logto активно разрабатывает решения, предлагающие простую конфигурацию и готовый опыт SSO-аутентификации. Ожидайте нашего предстоящего выпуска, в котором мы более подробно рассмотрим конкретные решения SP-инициированного SSO.