Архитектура удостоверений Azure Stack Hub
При выборе поставщика удостоверений для использования с Azure Stack Hub необходимо ознакомиться с существенными различиями между вариантами Azure Active Directory (Azure AD) и службы федерации Active Directory (AD FS).
Возможности и ограничения
Выбранный поставщик удостоверений может ограничить некоторые возможности, включая поддержку мультитенантности.
| Возможность или сценарий | Azure AD | AD FS |
|---|---|---|
| С подключением к Интернету | да | Необязательно |
| Поддержка мультитенантности | Да | Нет |
| Элементы предложения в Marketplace | Да | Да (требуется использовать автономное средство синдикации Marketplace ) |
| Поддержка библиотеки проверки подлинности Active Directory (ADAL) | Да | Да |
| Поддержка таких средств, как Azure CLI, Visual Studio и PowerShell | Да | Да |
| Создание субъектов-служб с помощью портала Azure | Да | Нет |
| Создание субъектов-служб с помощью сертификатов | Да | Да |
| Создание субъектов-служб с помощью секретов (ключей) | Да | Да |
| Приложения могут использовать службу Graph | Да | Нет |
| Приложения могут использовать поставщика удостоверений для входа в систему | Да | Да. Требуется, чтобы приложения создавали федерацию с локальными экземплярами федерации AD FS. |
| Управляемые удостоверения | Нет | Нет |
Топологии
В следующих разделах рассматриваются разные топологии удостоверений, которые можно использовать.
Однотенантная топология Azure Active Directory
По умолчанию при установке Azure Stack Hub и использовании Azure AD Azure Stack Hub использует однотенантную топологию.
Однотенантная топология полезна в следующих случаях:
- Все пользователи входят в состав одного клиента.
- Экземпляр Azure Stack Hub для организации размещен в поставщике услуг.
Характеристики этой топологии:
- Azure Stack Hub регистрирует все приложения и службы в одном каталоге клиента Azure AD.
- В Azure Stack Hub выполняется проверка подлинности пользователей и приложений из этого каталога, в частности маркеров.
- Удостоверения администраторов (операторы облака) и пользователей находятся в одном клиенте каталога.
- Чтобы разрешить пользователю из другого каталога доступ к этой среде Azure Stack Hub, необходимо пригласить пользователя в качестве гостя в каталог клиента.
Мультитенантная топология Azure AD
Операторы облака могут настроить Azure Stack Hub, разрешив доступ к приложениям клиентам из одной или нескольких организаций. Пользователи получают доступ к приложениям через портал пользователей Azure Stack Hub. В этой конфигурации доступ к порталу администратора (используемый оператором облака) ограничен пользователями из одного каталога.
Топология с несколькими клиентами полезна, если:
- Поставщик услуг хочет предоставить доступ к Azure Stack Hub пользователям из нескольких организаций.
Характеристики этой топологии:
- Доступ к ресурсам необходимо предоставлять отдельно для каждой организации.
- Пользователи из одной организации не должны иметь возможность предоставлять доступ к ресурсам пользователям за пределами этой организации.
- Удостоверения администраторов (операторов облака) и пользователей могут находиться в разных клиентах каталога. Подобное разделение обеспечивает изоляцию учетной записи на уровне поставщика удостоверений.
AD FS
Топология AD FS необходима в следующих случаях:
- В Azure Stack Hub нет подключения к Интернету.
- 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.