CIAM 101: Аутентификация, Идентификация, SSO

Основы#

Я начал строить Logto, потому что заметил, что Управление Идентификацией и Доступом (IAM) со временем стало все более сложным и обширным. Концепция IAM достаточно велика, чтобы породить новые концепции, такие как WIAM (Workforce IAM) и CIAM (Customer IAM).

Хотя WIAM и CIAM имеют общую основу, их сценарии использования различны: WIAM обычно используется для внутренних пользователей, а CIAM — для внешних клиентов. Некоторые примеры:

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

Logto начал с CIAM по различным причинам (у нас будет еще одна статья, посвященная этому). Во время разработки мы поняли, что создание единого понимания внутри команды будет полезным, прежде чем вывести наш продукт на новый уровень. Мы надеемся, что это также поможет вам лучше разобраться в ландшафте IAM.

Давайте начнем!

Основы CIAM#

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

Аутентификация и авторизация#

💡 Аутентификация изначально определяется как "Кто ты?". Однако при обсуждении цифровых идентичностей более точно продемонстрировать аутентификацию через "доказательство владения идентичностью". (Благодарность Calm-Card-2424)

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

• Примеры для аутентификации
  • Вход с паролем, беспарольный вход, вход через социальные сети и т. д.
  • Машина-к-машине аутентификация
• Примеры для авторизации
  • Ролевое управление доступом
  • Управление доступом, основанное на атрибутах
• Примеры исключений
  • Неидентичные данные
  • Веб-хуки

Идентичность и арендатор#

Идентичность обычно представляет либо пользователя, либо машину. После успешной аутентификации как Идентичность выдается токен ID.

Другими словами, основной целью аутентификации является получение Идентичности.

Арендатор — это группа идентичностей:

Когда мы обсуждаем "многопользовательскую аренду", мы имеем в виду несколько экземпляров Logto, которые изолированы друг от друга. Другими словами, несколько экземпляров Logto.

Обратите внимание, что у них есть две изолированные системы идентичности, т.е. вы не можете использовать Идентичность арендатора 1 у арендатора 2, даже для одного и того же идентификатора (электронная почта, телефон и т. д.). Это как ваша членская карта Costco, недействительная в Whole Foods.

Приложение и арендатор#

Как и Идентичность, Приложение также принадлежит одному из арендаторов. Несколько вещей для запоминания:

• Обычно нет прямой связи между Приложением и Идентичностью.
  • Идентичность может представлять Приложение, но между ними нет прямой связи.
• Как и пользователи, приложения также находятся на уровне арендатора.
• Приложения - это код, тогда как пользователи - люди.
• Единственной целью Приложений является завершение аутентификации, т.е. получение Идентичности.

Провайдер Идентичности (IdP) и Провайдер Услуг (SP)#

Разница между этими двумя провайдерами на первый взгляд кажется запутанной, но важной.

• Провайдер Идентичности — это служба, которая предоставляет аутентификацию (AuthN) и выдает идентичности.

Вы можете найти различные объяснения о провайдерах услуг в Google, хотя они могут быть недостаточно удовлетворительными. В моем понимании, Провайдер Услуг — это относительное понятие:

• Провайдер Услуг (или Доверенная сторона в OIDC) — это служба или клиент, который инициирует аутентификацию (AuthN) и запрашивает результат у Провайдеров Идентичности.

Викторина#

Рассмотрим типичный сценарий социального входа в систему:

❓ Сколько провайдеров услуг и провайдеров идентичности на этой диаграмме?

Ответ

Оба по два. iOS приложение — это провайдер услуг для Logto, а Logto — провайдер идентичности. Logto также провайдер услуг для GitHub, а GitHub — провайдер идентичности. Таким образом, Logto является как Провайдером Услуг, так и Провайдером Идентичности.

Изучение кейса: компания по технологическим решениям#

Ты CTO технологической компании, у тебя есть более 100 бизнес-партнеров, и ты реализовал более 300 проектов.

• Каждый проект — это либо веб-приложение, либо мобильное приложение с бэкэнд-сервисом.
• Для каждого бизнес-партнёра ты хочешь переделать пользовательскую систему, чтобы обеспечить SSO для всех его проектов.

❓ Как Logto (или продукт CIAM) может помочь?

Ответ

Создайте экземпляр Logto для каждого бизнес-партнёра. Каждый партнёр обладает арендатором. Проекты сопоставляются с "Приложениями" в Logto.

Logto предлагает универсальный опыт входа (т.е. SSO) в рамках одного арендатора, поэтому пользователям не нужно заново входить в систему при доступе к другому приложению в том же арендаторе, если они уже вошли в него.

О чем мы говорим, когда говорим о SSO#

Мы заметили, что термин “SSO” часто вызывает путаницу. Мы считаем единую регистрацию (SSO) действием, а не бизнес-концепцией. Поэтому SSO не эквивалентно “SSO в WIAM”.

Когда мы говорим “это требует SSO”, это может относиться к одному из следующих случаев:

Случай SSO 1#

👉🏽 В крупной корпорации сотрудники используют одно и то же имя пользователя для входа во все ресурсы, лицензированные компанией (например, электронная почта, IM, облачные сервисы).

Это типичный сценарий WIAM. В этом случае участвует только один Провайдер Идентичности. Сейчас нас это не интересует.

Случай SSO 2#

👉🏽 Конечные пользователи используют одни и те же учетные данные для входа во все сервисы, разработанные одной компанией (например, GSuite).

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

Несмотря на это, Logto остается единственным источником правды о Идентичностях, просто "заимствуя" их у других провайдеров. В этом случае Logto действует как Провайдер Идентичностей (для приложений GSuite) и как Провайдер Услуг (для внешних Провайдеров Идентичностей).

Случай SSO 3#

👉🏽 Конечные пользователи могут использовать для завершения аутентификации только определенного Провайдера Идентичностей в соответствующем домене электронной почты. Например, вход в Figma с Google Workspace.

Это самый распространенный случай использования SSO в CIAM. Давайте рассмотри его ближе.

Если мы хотим войти в Figma, используя нашу электронную почту @silverhand.io, мы можем использовать либо Социальный вход, либо SSO. На рисунках ниже показаны различия между этими двумя вариантами:

В словах:

• После социального входа пользователи могут установить пароль или изменить адрес электронной почты в Figma
• После SSO пользователи не могут установить пароль или изменить какую-либо личную информацию, включая адрес электронной почты, так как их Идентичности управляются Google Workspace

В этом случае Logto является как Провайдером Идентичностей, так и Провайдером Услуг. Кажется, что SSO сложнее обычного процесса входа. Каковы преимущества для владельца идентичности?

• Централизованный контроль: Храните информацию о пользователях и процессы аутентификации в одном месте и гарантируйте, что информация о пользователях всегда актуальна. Нет необходимости добавлять и удалять лицензии в разных приложениях для изменения.
• Улучшенный пользовательский опыт: Владельцы идентичности, которым требуется SSO, обычно корпорации. Их сотрудники могут использовать одни и те же учетные данные и общую сессию для приложений внутри компании, таких как Figma, Zoom, Slack и т. д.
• Повышенная безопасность: Вы могли заметить, что некоторые корпорации требуют определенных методов входа, таких как динамические коды подтверждения. Использование SSO может гарантировать, что каждый сотрудник использует одинаковую комбинацию методов входа для доступа ко всем ресурсам.

🤔 Вы, умный человек, наверняка заметили, что это на самом деле Случай SSO 1 с точки зрения SaaS.

Пора обсудить "X" на диаграмме SSO. Это представляет собой процесс подключения Figma домена электронной почты к определенному Провайдеру Идентичностей. Но как это работает?

Маппинг SSO#

Поскольку запрос часто исходит от корпоративных клиентов, мы называем процесс “случая SSO 3” из предыдущего раздела "Корпоративный SSO" для ясности.

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

Действие процесса “X” теперь ясно:

🔍 Найти сопоставленный метод Корпоративного SSO для указанного домена электронной почты

Таким образом, если вы настроите silverhand.io как действующий домен электронной почты, который соединяется с URL-адресом Google Workspace SSO, пользователи, которые пытаются войти с почтой @silverhand.io, будут перенаправлены на соответствующую страницу входа в Google Workspace, а не обрабатываться на месте.

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

1. Что если у вас сотни или тысячи клиентов Корпоративного SSO?
2. Какова взаимосвязь между “обычными пользователями” и “пользователями Корпоративного SSO”?
3. Должны ли данные быть изолированы между разными клиентами Корпоративного SSO?
4. Нужно ли предоставлять панель для администраторов Корпоративного SSO для просмотра активных пользователей, журналов аудита и т. д.?
5. Как можно автоматически отключать учетную запись, когда пользователь удаляется из Провайдера Идентичностей Корпоративного SSO?

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

• Если пользователь может доказать владение этим доменом, он может настроить корпоративный SSO этого домена самостоятельно.

Это решение адресует первые два вопроса:

1. Что если у вас сотни или тысячи клиентов Корпоративного SSO?

• Они могут настроить Корпоративный SSO самостоятельно.

2. Какова взаимосвязь между “обычными пользователями” и “пользователями Корпоративного SSO”?

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

Как насчет третьего вопроса:

3. Должен ли я изолировать данные между разными клиентами Корпоративного SSO?

• Да и нет. Пора ввести организацию.

Организация#

Мы упомянули использование доменов электронной почты для распознавания конкретного метода Корпоративного SSO; другими словами, применение специального подхода к определенной группе пользователей.

Однако требования клиентов часто выходят за рамки простого Корпоративного SSO; например, вопросы 4 и 5 из предыдущего раздела. За эти годы, зрелая модель была разработана выдающимися компаниями SaaS, чтобы решить такие проблемы: Организации.

Правила организации

1. Организация — это группа идентичностей, обычно меньше арендатора.
2. Все организации связаны с арендатором.

Вы можете увидеть другие термины, такие как “Рабочее пространство”, “Команда” или даже “Арендатор” в ПО. Чтобы идентифицировать, если это концепция, о которой мы говорим, просто проверьте, означает ли она “группу идентичностей”.

В этой статье мы будем использовать термин "Организация" для последовательности.

В Notion вы можете создать и присоединиться к нескольким рабочим пространствам (т.е. Организациям) с тем же адресом электронной почты и легко переключаться между ними.

Для Slack, кажется, что это то же самое, но мы подозреваем, что используются разные Идентичности, так как нам нужно создавать новую учетную запись для каждого рабочего пространства.

У Notion есть “Личный план”, который обычно является Организацией под капотом, где находится единственный пользователь (вы). Мы не знаем точной реализации Notion, но это объяснение обосновано и достижимо для нашей модели.

Каждая Организация также имеет идентификатор, обычно называемый “доменом Организации”.

Викторина#

❓ Может ли приложение быть связано с Организацией?

Ответ

Да да. Как мы обсуждали в начале, приложение может иметь Идентичность. Можете ли вы подробно описать бизнес-сценарий для этого?

Оставшиеся вопросы#

3. Должны ли данные быть изолированы между разными клиентами Корпоративного SSO?

• Да: изолировать бизнес-данные, такие как сообщения и документы, на уровне Организации.
• Нет: оставить независимые Идентичности, так как они не нуждаются в ассоциации с Организацией.
• Обратите внимание, здесь участвуют три различных образования: Идентичности, Организации и конфигурации Корпоративного SSO; которые существенно увеличивают сложность. Сам вопрос недостаточно конкретен.

4. Нужно ли предоставлять панель для администраторов Корпоративного SSO для просмотра активных пользователей, журналов аудита и т. д.?

5. Как автоматически отключать учетную запись, когда пользователь удаляется из Провайдера Идентичностей Корпоративного SSO?

• Эти требования больше ориентированы на бизнес и могут быть реализованы на уровне Организации. Мы оставим их открытыми здесь.

Заключительные замечания#

Мы ввели несколько концепций: Аутентификация (AuthN), Авторизация (AuthZ), Идентичность, Арендатор, Приложение, Провайдер Идентичности (IdP), Провайдер Услуг (SP), Едина система входа (SSO), и Корпоративная SSO (Организация). Может потребоваться некоторое время, чтобы понять их все.

Во время написания этой статьи, я заметил, что интересно, что самые дорогие планы онлайн-сервисов часто включают эксклюзивные функции, связанные с авторизацией, которые совершенно не упомянуты в этой статье. У вас уже могут быть некоторые вопросы об авторизации, такие как:

• Как мы можем назначать разрешения пользователю и проверять их?
• Какую модель авторизации я должен использовать?
• Какова лучшая практика для применения модели авторизации?