Общие сведения о поставщиках удостоверений для Azure Stack Hub

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

Выбор между Azure AD или AD FS определяется режимом, в котором вы развертываете Azure Stack Hub.

  • Если вы выполнили развертывание в режиме с подключением, можно использовать Azure AD или AD FS.
  • Если вы выполнили развертывание в отключенном режиме без подключения к Интернету, поддерживается только AD FS.

В зависимости от среды Azure Stack Hub изучите дополнительные сведения о доступных вариантах в следующих статьях:

Важно!

Azure AD Graph устарела и будет прекращена 30 июня 2022 г. Дополнительные сведения см. в этом разделе.

Общие понятия о поставщиках удостоверений

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

Terminology for identity providers

Организации и клиенты каталога

Каталог — это контейнер, содержащий сведения о пользователях, приложениях, группах и субъектах-службах.

Клиент каталога — это организация, например Майкрософт или ваша собственная компания.

  • Azure AD поддерживает нескольких клиентов и может поддерживать несколько организаций (каждую в собственном каталоге). Если вы используете Azure AD и имеете несколько клиентов, можно предоставить приложениям и пользователям из одного клиента доступ к другим клиентам того же каталога.
  • AD FS поддерживает только один клиент, и, следовательно, только одну организацию.

Пользователи и группы

Учетные записи пользователей (удостоверения) — это стандартные учетные записи, выполняющие проверку подлинности отдельных пользователей с помощью идентификатора и пароля пользователя. Группы могут содержать пользователей или другие группы.

Способ создания пользователей и групп и управление ими зависит от используемого вами решения для идентификации.

В Azure Stack Hub учетные записи пользователей имеют следующие свойства.

  • Создаются в формате username@domain . Хотя AD FS сопоставляет учетные записи пользователей с экземпляром Active Directory, AD FS не поддерживает использование формата \<domain>\<alias> .
  • Настраиваются для использования многофакторной проверки подлинности.
  • Ограничены каталогом, в котором они были впервые зарегистрированы. Это каталог организации.
  • Их можно импортировать из локальных каталогов. Дополнительные сведения см. в статье "Интеграция локальных каталогов с Azure Active Directory".

При входе на портал пользователей вашей организации вы используете URL-адрес https://portal.local.azurestack.external. При входе на портал Azure Stack Hub из других доменов, кроме указанного при регистрации Azure Stack Hub, необходимо добавить к URL-адресу портала имя домена, которое использовалось для регистрации Azure Stack Hub. Например, если Azure Stack Hub зарегистрирован в fabrikam.onmicrosoft.com и войдите в admin@contoso.comучетную запись пользователя, URL-адрес для входа на пользовательский портал будет следующим: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Гостевые пользователи

Гостевые пользователи — это учетные записи пользователей из других клиентов каталога, которым предоставили доступ к ресурсам в вашем каталоге. Для поддержки гостевых пользователей используйте Azure AD и включите поддержку мультитенантного режима. Если поддержка включена, вы можете предоставить гостевому пользователю доступ к ресурсам в вашем клиенте каталога. Это в свою очередь позволяет активировать совместную работу за пределами организации.

Чтобы пригласить гостевых пользователей, операторы облака и пользователи могут использовать службу совместной работы Azure AD B2B. Приглашенные пользователи получают доступ к документам, ресурсам и приложениям из вашего каталога, сохраняя при этом контроль над собственными ресурсами и данными.

В качестве гостевого пользователя вы можете войти в другой клиент каталога организации. Для этого добавьте имя каталога организации в URL-адрес портала. Например, если вы принадлежите организации Contoso и хотите войти в каталог Fabrikam, используйте https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Приложения

Вы можете зарегистрировать приложения в Azure AD или AD FS, а затем предложить их пользователям в организации.

В число приложений входят:

  • Веб-приложения: это, например, портал Azure и Azure Resource Manager. Они поддерживают вызовы веб-API.
  • Собственный клиент. В качестве примера можно привести Azure PowerShell, Visual Studio и Azure CLI.

Приложения могут поддерживать два типа клиентской модели:

  • Один арендатор: поддерживает пользователей и службы только из того же каталога, в котором зарегистрировано приложение.

    Примечание

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

  • Несколько арендаторов: поддерживает использование пользователями и службами из каталога, в котором зарегистрировано приложение, и других каталогов арендаторов. С помощью мультитенантных приложений пользователи из другого каталога клиента (другого клиента Azure AD) могут войти в ваше приложение.

    Дополнительные сведения о мультитенантности см. в статье Поддержка мультитенантности в Azure Stack.

    Дополнительные сведения о разработке мультитенантного приложения см. в статье Как реализовать вход любого пользователя Azure Active Directory (AD) с помощью шаблона мультитенантного приложения.

При регистрации приложения создаются два объекта:

  • Объект приложения: глобальное представление приложения во всех арендаторах. С программным приложением устанавливается отношение "один к одному", которое существует только в каталоге, в котором оно было впервые зарегистрировано.

  • Объект субъекта службы: учетные данные, которые создаются для приложения в каталоге, в котором оно зарегистрировано впервые. Субъект-служба также создается в каталоге каждого дополнительного клиента, в которых используется это приложение. С программным приложением может устанавливаться отношение "один ко многим".

Дополнительные сведения об объектах приложения и субъектах-службы см. в статье Объекты приложения и субъекта-службы в Azure Active Directory.

Субъекты-службы

Субъект-служба — это набор учетных данных для приложения или службы, которые предоставляют доступ к ресурсам в Azure Stack Hub. Использование субъекта-службы разделяет разрешения приложения от разрешений пользователя приложения.

Субъект-служба создается в каждом клиенте, в котором используется приложение. Она создает удостоверения для входа и доступа к ресурсам (например, пользователям), защищенных этим клиентом.

  • Приложение с одним клиентом имеет только один субъект-службу в каталоге, в котором оно впервые создано. Субъект-служба создается и дает согласие быть использованной во время регистрации приложения.
  • Для мультитенантного веб-приложения или API есть субъект-служба, которая будет создана в каждом клиенте, пользователь которого даст согласие на его использование.

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

Примечание

При использовании AD FS с Azure Stack Hub только администраторы могут создавать субъекты-службы. При использовании AD FS для субъектов-служб требуются сертификаты. В таком случае субъекты-службы создаются с помощью привилегированной конечной точки. Инструкции см. в статье Использование удостоверения приложения для доступа к ресурсам.

Дополнительные сведения о субъектах-службах для Azure Stack Hub см. в этой статье.

Службы

Службы в Azure Stack Hub, которые взаимодействуют с поставщиками удостоверений, регистрируются как приложения с поставщиком удостоверений. Как и в случае с приложениями, регистрация позволяет службе выполнить проверку подлинности с помощью системы идентификации.

Все службы Azure используют протоколы OpenID Подключение и веб-токены JSON для установления их удостоверения. Так как Azure AD и AD FS постоянно используют протоколы, вы можете использовать библиотеку проверки подлинности Azure Active Directory (ADAL) для проверки подлинности в локальной среде или в Azure (в подключенном сценарии). С помощью ADAL также можно использовать такие средства, как Azure PowerShell и Azure CLI, для управления ресурсами в локальной среде и в нескольких облаках.

Удостоверения и система идентификации

К удостоверениям для Azure Stack Hub относятся учетные записи пользователей, группы и субъекты-службы.

При установке Azure Stack Hub несколько встроенных приложений и служб автоматически регистрируются в поставщике удостоверений в клиенте каталога. Некоторые регистрируемые службы используются для администрирования. Другие службы доступны для пользователей. При стандартной регистрации основные службы получают удостоверения, которые могут взаимодействовать между собой и с удостоверениями, которые будут добавлены позже.

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

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

Проверка подлинности, выполняемая приложениями и пользователями

Identity between layers of Azure Stack Hub

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

Уровень Проверка подлинности между слоями
Средства и клиенты, например портал администрирования Для доступа или изменения ресурса в Azure Stack Hub средства и клиенты используют веб-маркер JSON для вызова azure Resource Manager.
Azure Resource Manager проверяет веб-маркер JSON и просматривает утверждения в выданном маркере, чтобы оценить уровень авторизации, который пользователь или субъект-служба имеет в Azure Stack Hub.
Платформа Azure Resource Manager и ее основные службы Azure Resource Manager взаимодействует с поставщиками ресурсов для передачи данных от пользователей.
Передача использует прямые императивные вызовы или декларативныевызовы через шаблоны Azure Resource Manager.
Поставщики ресурсов Вызовы, передаваемые поставщикам удостоверений, защищены проверкой подлинности на основе сертификатов.
Azure Resource Manager и поставщик удостоверений затем взаимодействуют с помощью API. Каждый вызов, полученный из Azure Resource Manager, поставщик удостоверений проверяет с помощью сертификата.
Инфраструктура и бизнес-логика Поставщики ресурсов взаимодействуют с бизнес-логикой и инфраструктурой с помощью режима проверки подлинности на свой выбор. Стандартные поставщики удостоверений, которые поставляются с Azure Stack Hub, используют проверку подлинности Windows для защиты этой связи.

Information needed for authentication

Проверка подлинности в Azure Resource Manager

Чтобы выполнить проверку подлинности с помощью поставщика удостоверений и получить JSON Web Token, необходимо иметь следующие сведения:

  1. URL-адрес для системы идентификации (центр). URL-адрес, по которому можно связаться с поставщиком удостоверений. Например, https://login.windows.net.
  2. URI идентификатора приложения для Azure Resource Manager: уникальный идентификатор для Azure Resource Manager, который регистрируется у вашего поставщика удостоверений. Он уникален для каждой установки Azure Stack Hub.
  3. Учетные данные. Учетные данные, которые вы используете для выполнения проверки подлинности с помощью поставщика удостоверений.
  4. URL-адрес для Azure Resource Manager. URL-адрес — это расположение службы Azure Resource Manager. Например, https://management.azure.com или https://management.local.azurestack.external.

Когда субъект (клиент, приложение или пользователь) выполняет запрос на проверку подлинности для доступа к ресурсу, запрос должен содержать следующие данные:

  • Учетные данные субъекта.
  • URI идентификатора приложения для ресурса, к которому субъект хочет получить доступ.

Учетные данные проверяются поставщиком удостоверений. Поставщик удостоверений также проверяет, чтобы URI идентификатора приложения использовался для зарегистрированного приложения и чтобы субъект имел правильные разрешения для получения маркера для ресурса. Если запрос допустимый, предоставляется JSON Web Token.

Затем маркер передается в заголовке запроса к Azure Resource Manager. Azure Resource Manager в любом порядке выполняет следующее:

  • Проверяет утверждение издателя, чтобы убедиться, что маркер получен из правильного поставщика удостоверений.
  • Проверяет утверждение аудитории, чтобы убедиться, что маркер был выдан Azure Resource Manager.
  • Проверяет, что JSON Web Token подписан с помощью сертификата, настроенного через OpenID, известного для Azure Resource Manager.
  • Просматривает утверждения времени выдачи и окончания срока действия, чтобы убедиться, что маркер активный и может быть принят.

После выполнения всех проверок, Azure Resource Manager использует утверждения идентификатора объекта (oid) и групп для создания списка ресурсов, к которым субъект может получить доступ.

Diagram of the token exchange protocol

Примечание

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

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

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

Проверка подлинности с помощью Azure PowerShell

Сведения об использовании Azure PowerShell для проверки подлинности в Azure Stack Hub см. в статье Подключение к Azure Stack в роли пользователя с помощью PowerShell.

Проверка подлинности с помощью Azure CLI

Сведения об использовании Azure CLI для проверки подлинности в Azure Stack Hub см. в статье Развертывание и администрирование ресурсов в Azure Stack с помощью Azure CLI.

Политика Azure

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

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

Примечание

Политика Azure в настоящее время не поддерживается в Azure Stack Hub.

Azure AD Graph

Microsoft Azure объявила о прекращении поддержки Azure AD Graph 30 июня 2020 г. и датой прекращения поддержки 30 июня 2022 г. Корпорация Майкрософт сообщила клиентам по электронной почте об этом изменении. В следующем разделе описывается, как это нерекомендуемо влияет на Azure Stack Hub.

Команда Azure Stack Hub тесно сотрудничает с командой azure Graph, чтобы при необходимости обеспечить беспроблемную работу систем после 30 июня 2022 г. Наиболее важным действием является обеспечение соответствия политике обслуживания Azure Stack Hub. Клиенты получат оповещение на портале администрирования Azure Stack Hub и потребуется обновить домашний каталог и все подключенные гостевые каталоги.

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

Если вы используете AD FS в качестве системы идентификации с Azure Stack Hub, эти Graph изменения не повлияют на вашу систему напрямую. Однако для последних версий таких средств, как Azure CLI, Azure PowerShell и т. д., потребуются новые api-интерфейсы Graph, и они не будут работать. Убедитесь, что вы используете только версии этих средств, которые явно поддерживаются в данной сборке Azure Stack Hub. Эта статья будет обновлена в будущем и список поддерживаемых версий инструментов для Azure Stack Hub для AD FS.

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

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