Архитектура удостоверений Azure Stack Hub

  • Статья

При выборе поставщика удостоверений для использования с Azure Stack Hub следует понимать важные различия между параметрами идентификатора Microsoft Entra и службы федерации Active Directory (AD FS) (AD FS).

Возможности и ограничения

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

Возможность или сценарий Microsoft Entra ID AD FS
С подключением к Интернету да Необязательно
Поддержка мультитенантности Да Нет
Элементы предложения в Marketplace Да Да (требуется использовать автономное средство синдикации Marketplace )
Поддержка библиотеки проверки подлинности Active Directory (ADAL) Да Да
Поддержка таких средств, как Azure CLI, Visual Studio и PowerShell Да Да
Создание субъектов-служб с помощью портала Azure Да Нет
Создание субъектов-служб с помощью сертификатов Да Да
Создание субъектов-служб с помощью секретов (ключей) Да Да
Приложения могут использовать службу Graph Да Нет
Приложения могут использовать поставщика удостоверений для входа в систему Да Да. Требуется, чтобы приложения создавали федерацию с локальными экземплярами федерации AD FS.
Управляемые удостоверения Нет Нет

Топологии

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

идентификатор Microsoft Entra: топология с одним клиентом

По умолчанию при установке Azure Stack Hub и использовании идентификатора Microsoft Entra Azure Stack Hub использует топологию с одним клиентом.

Однотенантная топология полезна в следующих случаях:

  • Все пользователи входят в состав одного клиента.
  • Экземпляр Azure Stack Hub для организации размещен в поставщике услуг.

Топология Azure Stack Hub с одним клиентом с идентификатором Microsoft Entra

Характеристики этой топологии:

  • Azure Stack Hub регистрирует все приложения и службы в одном каталоге клиента Microsoft Entra.
  • В Azure Stack Hub выполняется проверка подлинности пользователей и приложений из этого каталога, в частности маркеров.
  • Удостоверения администраторов (операторы облака) и пользователей находятся в одном клиенте каталога.
  • Чтобы разрешить пользователю из другого каталога доступ к этой среде Azure Stack Hub, необходимо пригласить пользователя в качестве гостя в каталог клиента.

идентификатор Microsoft Entra: топология с несколькими клиентами

Операторы облака могут настроить Azure Stack Hub, разрешив доступ к приложениям клиентам из одной или нескольких организаций. Пользователи получают доступ к приложениям через портал пользователей Azure Stack Hub. В этой конфигурации доступ к порталу администратора (используемый оператором облака) ограничен пользователями из одного каталога.

Топология с несколькими клиентами полезна, если:

  • Поставщик услуг хочет предоставить доступ к Azure Stack Hub пользователям из нескольких организаций.

Мультитенантная топология Azure Stack Hub с идентификатором Microsoft Entra

Характеристики этой топологии:

  • Доступ к ресурсам необходимо предоставлять отдельно для каждой организации.
  • Пользователи из одной организации не должны иметь возможность предоставлять доступ к ресурсам пользователям за пределами этой организации.
  • Удостоверения администраторов (операторов облака) и пользователей могут находиться в разных клиентах каталога. Подобное разделение обеспечивает изоляцию учетной записи на уровне поставщика удостоверений.

AD FS

Топология AD FS необходима в следующих случаях:

  • В Azure Stack Hub нет подключения к Интернету.
  • Azure Stack Hub можно подключить к Интернету, но вы решили использовать AD FS в качестве поставщика удостоверений.

Топология Azure Stack Hub, использующая AD FS

Характеристики этой топологии:

  • Для использования этой топологии в рабочей среде нужно интегрировать встроенный экземпляр Azure Stack Hub AD FS с существующим экземпляром AD FS, поддерживаемым Active Directory (AD) с помощью отношения доверия федерации.

  • Кроме того, можно интегрировать службу Graph в Azure Stack Hub с существующим экземпляром Active Directory. Кроме того, вы можете использовать протокол OData на основе службы API Graph, который поддерживает программные интерфейсы, совместимые с API Graph Azure AD.

    Для взаимодействия с экземпляром Active Directory API Graph требуются учетные данные пользователя с разрешением только на чтение для вашего экземпляра Active Directory и доступ к:

    • Встроенный экземпляр AD FS.
    • Экземпляры AD FS и Active Directory, которые должны быть основаны на Windows Server 2012 или более поздней версии.

    Взаимодействие между экземпляром Active Directory и встроенным экземпляром AD FS не ограничено только OpenID Connect. Поэтому вы можете использовать любой поддерживаемый протокол.

    • Учетные записи пользователей создаются и управляются в локальном экземпляре Active Directory.
    • Субъекты-службы и регистрации для приложений управляются встроенным экземпляром Active Directory.

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