Поделиться через

Руководство: настройка Ping Identity для работы с Azure Active Directory B2C в целях обеспечения безопасного гибридного доступа

  • Статья

В этом руководстве описано, как расширить возможности Azure Active Directory B2C (Azure AD B2C) с помощью PingAccess и PingFederate. PingAccess предоставляет доступ к приложениям и API, а также обработчик политик для авторизованного доступа пользователей. PingFederate — это корпоративный сервер федерации для проверки подлинности пользователей и единого входа, который позволяет клиентам, сотрудникам и партнерам получать доступ к приложениям с устройств. Используйте их вместе для обеспечения безопасного гибридного доступа (SHA).

Многие сайты электронной коммерции и веб-приложения, доступные в Интернете, развертываются за прокси-системами или системой обратного прокси-сервера. Эти прокси-системы предварительно проходят проверку подлинности, применяют политику и маршрутит трафик. Типичные сценарии включают защиту веб-приложений от входящего веб-трафика и обеспечение единообразного управления сеансами в развертываниях распределенных серверов.

Как правило, конфигурации включают уровень преобразования проверки подлинности, который удаляет проверку подлинности из веб-приложения. Обратные прокси-серверы предоставляют веб-приложениям контекст пользователя, прошедший проверку подлинности, например значение заголовка в виде clear или digest. Приложения не используют стандартные отраслевые маркеры, такие как SAML, OAuth или OpenID Connect (OIDC). Вместо этого прокси-сервер предоставляет контекст проверки подлинности и поддерживает сеанс с агентом конечного пользователя, например браузером или собственным приложением. Прокси-серверы, работающие как служба "человек в середине", обеспечивают значительное управление сеансами. Прокси-служба является эффективной и масштабируемой, а не узким местом для приложений, стоящих за прокси-службой. Схема представляет собой реализацию обратного прокси-сервера и поток обмена данными.

Схема реализации обратного прокси-сервера.

Модернизация

Если вы хотите модернизировать платформу удостоверений в таких конфигурациях, могут возникнуть проблемы с клиентами:

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

В ответ на эти проблемы в этом руководстве используется Azure AD интеграции B2C, PingAccess и PingFederate.

Общая среда

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

Azure AD B2C в качестве поставщика удостоверений

В Azure AD B2C вы определяете политики, которые управляют взаимодействием и поведением пользователей, также называемые пути взаимодействия пользователей. Каждая такая политика предоставляет конечную точку протокола, которая может выполнять проверку подлинности в качестве поставщика удостоверений. На стороне приложения для определенных политик не требуется специальная обработка. Приложение выполняет стандартный запрос проверки подлинности к конечной точке проверки подлинности для конкретного протокола, предоставляемой политикой.
Вы можете настроить Azure AD B2C для совместного использования одного издателя в разных политиках или уникального издателя для каждой политики. Каждое приложение может указывать на политики, выполняя запрос проверки подлинности на основе протокола, который управляет поведением пользователя, таким как вход, регистрация и изменение профиля. На схеме показаны рабочие процессы приложения с использованием OIDC и SAML.

Схема рабочих процессов приложения OIDC и SAML.

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

Обратный прокси-сервер PingAccess

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

Настройте PingAccess с помощью OIDC, OAuth2 или SAML для проверки подлинности с помощью поставщика проверки подлинности вышестоящий. Для этой цели можно настроить вышестоящий поставщика удостоверений на сервере PingAccess. Рассмотрим схему ниже.

Схема вышестоящий поставщика удостоверений на сервере PingAccess.

В типичном Azure AD развертывании B2C с политиками, предоставляющими поставщиков удостоверений, существует проблема. Для PingAccess настроен один поставщик удостоверений вышестоящий.

Прокси-сервер федерации PingFederate

PingFederate можно настроить в качестве поставщика проверки подлинности или прокси-сервера для поставщиков удостоверений вышестоящий. Рассмотрим схему ниже.

Схема PingFederate, настроенная поставщиком проверки подлинности или прокси-сервером для вышестоящий IDP.

Используйте эту функцию для контекстного, динамического или декларативного переключения входящего запроса на политику B2C Azure AD. См. следующую схему потока последовательности протоколов.

Схема потока последовательности протоколов для PingAccess, PingFederate, Azure AD B2C и приложения.

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

Чтобы приступить к работе, вам потребуется:

Подключение и связь

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

  • Сервер PingAccess — обменивается данными с сервером PingFederate, клиентским браузером, OIDC, OAuth и обнаружением ключей, опубликованными службой Azure AD B2C и сервером PingFederate.
  • Сервер PingFederate — взаимодействует с сервером PingAccess, клиентским браузером, OIDC, OAuth и обнаружением ключей, опубликованным службой Azure AD B2C.
  • Устаревшее приложение или приложение AuthN на основе заголовков — обменивается данными с сервером PingAccess и с сервера PingAccess.
  • Приложение проверяющей стороны SAML — достигает трафика браузера от клиента. Обращается к метаданным федерации SAML, опубликованным службой Azure AD B2C.
  • Современное приложение — достигает трафика браузера от клиента. Обращается к хорошо известным OIDC, OAuth и обнаружению ключей, опубликованным службой Azure AD B2C.
  • REST API — достигает трафика от собственного или веб-клиента. Обращается к хорошо известным OIDC, OAuth и обнаружению ключей, опубликованным службой Azure AD B2C.

Настройка Azure AD B2C

Вы можете использовать базовые потоки пользователей или расширенные политики Identity Enterprise Framework (IEF). PingAccess создает конечную точку метаданных на основе значения издателя, используя протокол WebFinger для соглашения об обнаружении. Чтобы следовать этому соглашению, обновите Azure AD издателя B2C, используя свойства политики потока пользователя.

Снимок экрана: URL-адрес дочернего утверждения субъекта в диалоговом окне

В расширенных политиках конфигурация включает элемент метаданных IssuanceClaimPattern в значение AuthorityWithTfp в техническом профиле издателя маркера JWT.

Настройка PingAccess и PingFederate

Следуйте инструкциям в следующих разделах, чтобы настроить PingAccess и PingFederate. См. следующую схему: общий поток пользователя интеграции.

Схема пользовательского потока интеграции PingAccess и PingFederate

Настройка PingFederate в качестве поставщика маркеров

Чтобы настроить PingFederate в качестве поставщика маркеров для PingAccess, обеспечьте подключение из PingFederate к PingAccess. Подтвердите подключение PingAccess к PingFederate.

Дополнительные сведения см. в разделе Настройка PingFederate в качестве поставщика маркеров для PingAccess в документации по Ping Identity.

Настройка приложения PingAccess для проверки подлинности на основе заголовков

Используйте следующие инструкции, чтобы создать приложение PingAccess для целевого веб-приложения для проверки подлинности на основе заголовков.

Создание виртуального узла

Важно!

Создайте виртуальный узел для каждого приложения. Дополнительные сведения см. в разделе Что можно настроить с помощью PingAccess? в документации по Ping Identity.

Чтобы создать виртуальный узел, выполните приведенные далее действия.

  1. Перейдите в раздел Параметры Доступ>к>виртуальным узлам.
  2. Выберите Добавить виртуальный узел.
  3. В поле Узел введите полное доменное имя url-адреса приложения.
  4. В поле Порт введите 443.
  5. Щелкните Сохранить.

Создание веб-сеанса

Чтобы создать веб-сеанс, выполните приведенные далее действия.

  1. Перейдите в раздел Параметры>Доступ к>веб-сеансам.
  2. Выберите Добавить веб-сеанс.
  3. Введите имя веб-сеанса.
  4. Выберите Тип файла cookie: Подписанный JWT или Зашифрованный JWT.
  5. Введите уникальное значение для параметра Аудитория.
  6. В поле Идентификатор клиента введите идентификатор приложения Microsoft Entra.
  7. В поле Секрет клиента введите ключ, созданный для приложения, в Microsoft Entra идентификатор.
  8. (Необязательно) Создание и использование настраиваемых утверждений с API Graph Майкрософт: выберите Дополнительно. Снимите флажки Профиль запроса и Обновить атрибуты пользователя. Дополнительные сведения о пользовательских утверждениях: Единый вход на основе заголовков для локальных приложений с Microsoft Entra прокси приложения.
  9. Нажмите кнопку Сохранить.

Создание сопоставления удостоверений

Примечание

Сопоставление удостоверений можно использовать с несколькими приложениями, если они ожидают одни и те же данные в заголовке.

Чтобы создать сопоставление удостоверений, выполните приведенные далее действия.

  1. Перейдите в раздел Параметры>Сопоставления удостоверенийдоступа>.
  2. Выберите Добавить сопоставление удостоверений.
  3. Укажите *Имя.
  4. Выберите тип сопоставления удостоверений заголовка.
  5. В таблице Attribute-Mapping (Сопоставление атрибутов) укажите необходимые сопоставления. Например,
Имя атрибута Имя заголовка
'upn' x-userprincipalname
'email' x-email
'oid' x-oid
'scp' x-scope
'amr' x-amr
  1. Нажмите кнопку Сохранить.

Создание сайта.

Примечание

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

Чтобы создать сайт, выполните приведенные далее действия.

  1. Перейдите в раздел Основные>сайты.
  2. Выберите Добавить сайт.
  3. Введите имя сайта.
  4. Укажите целевой сервер для сайта в поле Target (Целевой сервер). Целевой сервер — это пара "имя узла: порт" для сервера, на котором размещено приложение. Не вводите путь к приложению в этом поле. Например, приложение в https://mysite:9999/AppName имеет целевое значение mysite:9999.
  5. Укажите, ожидает ли целевой объект безопасные подключения.
  6. Если целевой объект ожидает безопасных подключений, задайте для группы доверенных сертификатов значение Доверять любым.
  7. Щелкните Сохранить.

Создание приложения

Создание приложения в PingAccess для каждого приложения в Azure, которое требуется защитить.

  1. Выберите Main (Главная) >Applications (Приложения).

  2. Выберите Add Application (Добавить приложение).

  3. Укажите имя приложения в поле Name (Имя).

  4. При необходимости также введите описание приложения в поле Description (Описание).

  5. Задайте корень контекста приложения в поле Context Root (Корень контекста). Например, у приложения с путем https://mysite:9999/AppName корень контекста будет /AppName. Корень контекста должен начинаться с косой черты (/), не должен заканчиваться косой чертой (/) и может иметь несколько уровней, например /Apps/MyApp.

  6. Выберите созданный ранее виртуальный узел.

    Примечание

    Сочетание виртуального узла и корня контекста должно быть уникальным в PingAccess.

  7. Выберите созданный ранее веб-сеанс.

  8. Выберите созданный на предыдущем шаге сайт, содержащий приложение.

  9. Выберите созданное ранее сопоставление удостоверений.

  10. Выберите Enabled (Включено), чтобы включить сайт при сохранении.

  11. Нажмите кнопку Сохранить.

Настройка политики проверки подлинности PingFederate

Настроив политику проверки подлинности PingFederate, вы можете объединить в федерацию несколько поставщиков удостоверений, предоставленных клиентами Azure AD B2C.

  1. Создайте контракт, чтобы установить мостовую связь между атрибутами IdP и SP. Вам потребуется только один контракт, если поставщику услуг не требуется отдельный набор атрибутов для каждого поставщика удостоверений. Дополнительные сведения см. в разделе Центр федерации и контракты политики проверки подлинности в документации по удостоверению проверки подлинности.

  2. Для каждого IdP создайте IdP-подключение между IdP и PingFederate, в котором центр федерации выступает как SP.

  3. В окне Target Session Mapping (Сопоставление целевых сеансов) добавьте в IdP-подключение применимые контракты политики проверки подлинности.

  4. В окне Selectors (Селекторы) настройте селектор проверки подлинности. В качестве примера ознакомьтесь с экземпляром Identifier First Adapter, чтобы связать каждый IdP с соответствующим IdP-подключением в политике проверки подлинности.

  5. Создайте SP-подключение между PingFederate и SP, в котором центр федерации выступает как IdP.

  6. Добавьте соответствующий контракт политики проверки подлинности в SP-подключение в окне Authentication Source Mapping (Сопоставление источника проверки подлинности).

  7. Подключите каждый IdP к PingFederate, чтобы центр федерации выступал как SP.

  8. Подключите каждый SP к PingFederate, чтобы центр федерации выступал как IdP.

Дальнейшие действия

Дополнительные сведения см. в следующих статьях: