Интеграция Auth0 с рабочими процессами Okta

Автор — Марк Смит, специалист по CIAM, Okta.

Customer Identity Cloud (она же Auth0 Identity Platform), продуктовое подразделение компании Okta, использует современный подход к идентификации и позволяет организациям обеспечить безопасный доступ к любому приложению для любого пользователя. Auth0 — это высоко настраиваемая платформа, которая настолько проста, насколько хотят команды разработчиков, и настолько гибкая, насколько им нужно. В современном продуктовом ландшафте все чаще можно увидеть совместную работу Okta и Auth0. Это может быть в рамках одного предприятия, где Okta обрабатывает внутренние идентификационные данные сотрудников, а Auth0 заботится об идентификационных данных клиентов, или в межкорпоративных средах, таких как B2B, где бизнес-партнер может использовать как один, так и другой продукт.

Okta Workflows позволяет легко автоматизировать процессы идентификации в масштабе — без написания кода. Используя логику «если то-то и то-то», библиотеку готовых коннекторов Okta, Connector Builder и возможность подключения к любому общедоступному API, любой может внедрять инновации с Okta. В этой записи блога мы рассмотрим использование рабочих процессов Okta для упрощения интеграции между Okta и Auth0.

Пример использования

Давайте начнем с реального простого случая использования, чтобы мы могли посмотреть, как мы можем интегрировать эти два продукта. Могут быть ситуации, подобные B2B, когда одна и та же личность существует и в Okta, и в Auth0. Если личность деактивирована в одной среде, то другая среда должна знать об этом. Поэтому в нашем примере, если пользователь деактивирован в Okta, мы обновим метаданные пользователя в Auth0, чтобы указать на изменение статуса. Затем Auth0 может уловить это изменение и отказать пользователю в доступе.

Этот простой поток описан на следующей диаграмме.

На приведенной выше диаграмме последовательность обработки выглядит как потоки:

1. Пользователь в Okta деактивируется (тот же пользователь также существует в Auth0).
2. Выполняется вызов Okta для получения адреса электронной почты пользователя.
3. Используя адрес электронной почты, мы вызываем Auth0 для получения уникального идентификатора пользователя Auth0.
4. Используя идентификатор, мы обновляем метаданные пользователя, чтобы включить флаг, указывающий на то, что пользователь был деактивирован в Okta.
5. Используя действие Auth0, мы проверяем метаданные пользователя во время входа в систему. Если метаданные указывают на то, что пользователь был деактивирован в Okta, то пользователю будет отказано в доступе.

Предварительные требования

Для реализации этого примера вам понадобится следующее:

1. Арендатор Okta
2. Арендатор Auth0
3. Рабочие процессы Okta, включенные в вашем арендаторе Okta.

Шаг 1 — Создание приложения Auth0

В консоли управления Auth0 перейдите в раздел Applications и создайте новое приложение типа Machine to Machine. Это приложение будет использовать Auth0 Management API и должно иметь возможность читать и обновлять пользователей.

После создания обратите внимание на следующие значения.

1. Домен
2. Идентификатор клиента
3. Секрет клиента

Вот пример:

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

Шаг 2 — Загрузка и импорт образцов потоков

Образцы потоков, демонстрирующие данный сценарий использования, можно найти здесь: auth0UserMetaData.folder

Создайте папку в Okta Workflows и импортируйте артефакт под названием auth0UserMetaData.folder.

После импорта у вас должны быть следующие потоки:

1. [main] User Deactivated — Это основной поток, который будет инициироваться каждый раз, когда пользователь в вашем соответствующем арендаторе Okta будет деактивирован.
2. [util] Get Access Token — Этот вспомогательный поток используется для вызова вашего арендатора Auth0 для генерации Access Token.
3. [util] Get Auth0 User Id — Этот вспомогательный поток используется для получения идентификатора Auth0 соответствующих пользователей на основе адреса электронной почты пользователей Okta.
4. [util] Get Configuration — Этот вспомогательный поток извлекает некоторые статические значения из таблицы конфигурации.
5. [util] Update Auth0 User — Этот вспомогательный поток используется для обновления пользователя Auth0 и установки флага в его пользовательских метаданных.

У вас также будет следующая таблица:

1. configuration — Используется для хранения некоторых статических значений конфигурации

Шаг 3 — Обновление образцовых потоков и таблицы

Следующим шагом будет обновление таблицы конфигурации для включения пар имя/значение для domain, client_id и client_secret. Это значения, сохраненные в шаге 1. После завершения таблица конфигурации должна выглядеть так, как показано в следующем примере:

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

Далее создайте коннектор Okta для вашего локального арендатора Okta, если он еще не существует в вашем экземпляре рабочего процесса.

Затем откройте поток под названием [main] User Deactivated и установите коннектор Okta для двух карточек Okta (User Deactivated и Read User). В качестве примера ниже показано начало основного потока примера. Мы видим, что карточки User Deactivated и Read User используют коннектор MS2 Okta. Обновите эти карточки, чтобы использовать свой собственный коннектор Okta.

Наконец, убедитесь, что все ваши потоки активированы.

Вот остаток моего основного потока:

Обработка основного потока происходит следующим образом:

1. Используя переданный идентификатор пользователя, считывается информация о пользователе, чтобы получить его основную электронную почту.
2. Вызов вспомогательного потока извлекает значения, хранящиеся в таблице конфигурации.
3. Вызов вспомогательного потока извлекает токен доступа Auth0 на основе сохраненного домена, идентификатора клиента и секрета клиента. Этот вспомогательный поток использует поток Client Credential.
4. Используя токен доступа, выполняется вызов вспомогательного потока для получения уникального идентификатора Auth0 пользователя.
5. Наконец, вызов вспомогательного потока выполняется для обновления метаданных пользователя, чтобы указать, что пользователь был деактивирован в Okta.

Шаг 4 — Создание действия Auth0

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

exports.onExecutePostLogin = async (event, api) => {
  if (event.user.user_metadata.okta.deactivated === "true") {
       api.access.deny(`Your account has been deactivated!`);
  };
};

Тестирование рабочего процесса

Чтобы протестировать рабочий процесс, убедитесь, что у вас есть один и тот же пользователь, существующий в Okta и Auth0. Затем деактивируйте пользователя в Okta. После этого рабочий процесс должен запуститься и обновить метаданные пользователя в Auth0.

Вот пример обновленных метаданных:

Теперь, если вы попытаетесь аутентифицироваться как этот пользователь в Auth0, вам будет отказано.