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

Для работы Azure Stack Hub требуется Azure Active Directory (Azure AD) или службы федерации Active Directory (AD FS) на базе Active Directory в качестве поставщика удостоверений.Azure Stack Hub requires Azure Active Directory (Azure AD) or Active Directory Federation Services (AD FS), backed by Active Directory as an identity provider. Решение о выборе поставщика принимается один раз во время развертывания Azure Stack Hub.The choice of a provider is a one-time decision that you make when you first deploy Azure Stack Hub. Основные понятия и сведения об авторизации из этой статьи могут помочь вам выбрать поставщика удостоверений.The concepts and authorization details in this article can help you choose between identity providers.

Выбор между Azure AD или AD FS определяется режимом, в котором вы развертываете Azure Stack Hub.Your choice of either Azure AD or AD FS is determined by the mode in which you deploy Azure Stack Hub:

  • Если вы выполнили развертывание в режиме с подключением, можно использовать Azure AD или AD FS.When you deploy it in a connected mode, you can use either Azure AD or AD FS.
  • Если вы выполнили развертывание в отключенном режиме без подключения к Интернету, поддерживается только AD FS.When you deploy it in a disconnected mode, without a connection to the internet, only AD FS is supported.

В зависимости от среды Azure Stack Hub изучите дополнительные сведения о доступных вариантах в следующих статьях:For more information about your options, which depend on your Azure Stack Hub environment, see the following articles:

Общие понятия о поставщиках удостоверенийCommon concepts for identity providers

В следующих разделах рассматриваются основные понятия, связанные с поставщиками удостоверений, и сведения об их использовании в Azure Stack Hub.The next sections discuss common concepts about identity providers and their use in Azure Stack Hub.

Терминология для поставщиков удостоверений

Организации и клиенты каталогаDirectory tenants and organizations

Каталог — это контейнер, который содержит информацию о пользователях, приложениях, группах и субъектах-служб.A directory is a container that holds information about users, applications, groups, and service principals.

Клиент каталога — это организация, например, корпорация Майкрософт или ваша компания.A directory tenant is an organization, such as Microsoft or your own company.

  • Azure AD поддерживает нескольких клиентов и может поддерживать несколько организаций (каждую в собственном каталоге).Azure AD supports multiple tenants, and it can support multiple organizations, each in its own directory. Если вы используете Azure AD и имеете несколько клиентов, можно предоставить приложениям и пользователям из одного клиента доступ к другим клиентам того же каталога.If you use Azure AD and have multiple tenants, you can grant apps and users from one tenant access to other tenants of that same directory.
  • AD FS поддерживает только один клиент, и, следовательно, только одну организацию.AD FS supports only a single tenant and, therefore, only a single organization.

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

Учетные записи пользователей (удостоверения) — это стандартные учетные записи, выполняющие проверку подлинности отдельных пользователей с помощью идентификатора и пароля пользователя.User accounts (identities) are standard accounts that authenticate individuals by using a user ID and password. Группы могут содержать пользователей или другие группы.Groups can include users or other groups.

Способ создания пользователей и групп и управление ими зависит от используемого вами решения для идентификации.How you create and manage users and groups depends on the identity solution you use.

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

  • Создаются в формате имя_пользователя@домен.Are created in the username@domain format. Хотя AD FS сопоставляет учетные записи пользователей с Active Directoryным экземпляром, AD FS не поддерживает использование \<domain>\<alias> формата.Although AD FS maps user accounts to an Active Directory instance, AD FS doesn't support the use of the \<domain>\<alias> format.
  • Настраиваются для использования многофакторной проверки подлинности.Can be set up to use multi-factor authentication.
  • Ограничены каталогом, в котором они были впервые зарегистрированы. Это каталог организации.Are restricted to the directory where they first register, which is their organization's directory.
  • Их можно импортировать из локальных каталогов.Can be imported from your on-premises directories. Дополнительные сведения см. в статье Интеграция локальных каталогов с Azure Active Directory.For more information, see Integrate your on-premises directories with Azure Active Directory.

Для входа на пользовательский портал организации используется URL-адрес https://portal.local.azurestack.external.When you sign in to your organization's user portal, you use the https://portal.local.azurestack.external URL. При входе на портал Azure Stack Hub из других доменов, кроме указанного при регистрации Azure Stack Hub, необходимо добавить к URL-адресу портала имя домена, которое использовалось для регистрации Azure Stack Hub.When signing into the Azure Stack Hub portal from domains other than the one used to register Azure Stack Hub, the domain name used to register Azure Stack Hub must be appended to the portal url. Например, если экземпляр Azure Stack Hub зарегистрирован с доменом fabrikam.onmicrosoft.com, а для входа используется учетная запись admin@contoso.com, URL-адрес для входа на пользовательский портал будет таким: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.For example, if Azure Stack Hub has been registered with fabrikam.onmicrosoft.com and the user account logging in is admin@contoso.com, the URL to use to log into the user portal would be: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

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

Гостевые пользователи — это учетные записи пользователей из других клиентов каталога, которым предоставили доступ к ресурсам в вашем каталоге.Guest users are user accounts from other directory tenants that have been granted access to resources in your directory. Для поддержки гостевых пользователей используйте Azure AD и включите поддержку мультитенантного режима.To support guest users, you use Azure AD and enable support for multi-tenancy. Если поддержка включена, вы можете предоставить гостевому пользователю доступ к ресурсам в вашем клиенте каталога. Это в свою очередь позволяет активировать совместную работу за пределами организации.When support is enabled, you can invite guest users to access resources in your directory tenant, which in turn enables their collaboration with outside organizations.

Чтобы пригласить гостевых пользователей, операторы и пользователи облака могут использовать службу совместной работы Azure AD B2B.To invite guest users, cloud operators and users can use Azure AD B2B collaboration. Приглашенные пользователи получают доступ к документам, ресурсам и приложениям из вашего каталога, сохраняя при этом контроль над собственными ресурсами и данными.Invited users get access to documents, resources, and apps from your directory, and you maintain control over your own resources and data.

В качестве гостевого пользователя вы можете войти в другой клиент каталога организации.As a guest user, you can sign in to another organization's directory tenant. Для этого добавьте имя каталога организации в URL-адрес портала.To do so, you append that organization's directory name to the portal URL. Например, если вы принадлежите к организации Contoso, но хотите войти в каталог Fabrikam, используйте этот URL-адрес для входа: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.For example, if you belong to the Contoso organization and want to sign in to the Fabrikam directory, you use https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

ПриложенияApps

Вы можете зарегистрировать приложения в Azure AD или AD FS, а затем предложить их пользователям в организации.You can register apps to Azure AD or AD FS, and then offer the apps to users in your organization.

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

  • Веб-приложения. В качестве примера можно привести портал Azure и Azure Resource Manager.Web apps: Examples include the Azure portal and Azure Resource Manager. Они поддерживают вызовы веб-API.They support Web API calls.
  • Собственный клиент. В качестве примера можно привести Azure PowerShell, Visual Studio и Azure CLI.Native client: Examples include Azure PowerShell, Visual Studio, and Azure CLI.

Приложения могут поддерживать два типа клиентской модели:Apps can support two types of tenancy:

  • Один клиент. Поддерживает пользователей и службы только из того же каталога, в котором зарегистрировано приложение.Single-tenant: Supports users and services only from the same directory where the app is registered.

    Примечание

    Так как AD FS поддерживает только один каталог, приложения, созданные в топологии AD FS, являются по своей природе приложениями с одним клиентом.Because AD FS supports only a single directory, apps you create in an AD FS topology are, by design, single-tenant apps.

  • Несколько клиентов. Поддерживает использование приложения пользователями и службами из каталога, в котором зарегистрировано приложение, и из дополнительных каталогов клиента.Multi-tenant: Supports use by users and services from both the directory where the app is registered and additional tenant directories. С помощью мультитенантных приложений пользователи из другого каталога клиента (другого клиента Azure AD) могут войти в ваше приложение.With multi-tenant apps, users of another tenant directory (another Azure AD tenant) can sign in to your app.

    Дополнительные сведения о мультитенантности см. в статье Поддержка мультитенантности в Azure Stack.For more information about multi-tenancy, see Enable multi-tenancy.

    Дополнительные сведения о разработке мультитенантного приложения см. в статье Как реализовать вход любого пользователя Azure Active Directory (AD) с помощью шаблона мультитенантного приложения.For more information about developing a multi-tenant app, see Multi-tenant apps.

При регистрации приложения создаются два объекта:When you register an app, you create two objects:

  • Объект приложения. Это глобальное представление приложения во всех клиентах.Application object: The global representation of the app across all tenants. С программным приложением устанавливается отношение "один к одному", которое существует только в каталоге, в котором оно было впервые зарегистрировано.This relationship is one-to-one with the software app and exists only in the directory where the app is first registered.

  • Объект субъекта-службы. Подтверждение компетенции, созданное для приложения в каталоге, в котором впервые зарегистрировано приложение.Service principal object: A credential that's created for an app in the directory where the app is first registered. Субъект-служба также создается в каталоге каждого дополнительного клиента, в которых используется это приложение.A service principal is also created in the directory of each additional tenant where that app is used. С программным приложением может устанавливаться отношение "один ко многим".This relationship can be one-to-many with the software app.

Дополнительные сведения об объектах приложения и субъектах-службы см. в статье Объекты приложения и субъекта-службы в Azure Active Directory.To learn more about app and service principal objects, see Application and service principal objects in Azure Active Directory.

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

Субъект-служба — это набор учетных данных для приложения или службы, которые предоставляют доступ к ресурсам в Azure Stack Hub.A service principal is a set of credentials for an app or service that grant access to resources in Azure Stack Hub. Использование субъекта-службы разделяет разрешения приложения от разрешений пользователя приложения.The use of a service principal separates the app permissions from the permissions of the user of the app.

Субъект-служба создается в каждом клиенте, в котором используется приложение.A service principal is created in each tenant where the app is used. Она создает удостоверения для входа и доступа к ресурсам (например, пользователям), защищенных этим клиентом.The service principal establishes an identity for sign-in and access to resources (such as users) that are secured by that tenant.

  • Приложение с одним клиентом имеет только один субъект-службу в каталоге, в котором оно впервые создано.A single-tenant app has only one service principal, which is in the directory where it's first created. Субъект-служба создается и дает согласие быть использованной во время регистрации приложения.This service principal is created and consents to being used during registration of the app.
  • Для мультитенантного веб-приложения или API есть субъект-служба, которая будет создана в каждом клиенте, пользователь которого даст согласие на его использование.A multi-tenant web app or API has a service principal that's created in each tenant where a user from that tenant consents to the use of the app.

В качестве учетных данных для субъектов-служб могут использоваться ключ, который был создан на портале Azure, или сертификат.Credentials for service principals can be either a key that's generated through the Azure portal or a certificate. Использование сертификата хорошо подходит для автоматизации, так как сертификаты считаются более безопасными, чем ключи.The use of a certificate is suited for automation because certificates are considered more secure than keys.

Примечание

При использовании AD FS с Azure Stack Hub только администраторы могут создавать субъекты-службы.When you use AD FS with Azure Stack Hub, only the administrator can create service principals. При использовании AD FS для субъектов-служб требуются сертификаты. В таком случае субъекты-службы создаются с помощью привилегированной конечной точки.With AD FS, service principals require certificates and are created through the privileged endpoint (PEP). Инструкции см. в статье Использование удостоверения приложения для доступа к ресурсам.For more information, see Use an app identity to access resources.

Дополнительные сведения о субъектах-службах для Azure Stack Hub см. в этой статье.To learn about service principals for Azure Stack Hub, see Create service principals.

СлужбыServices

Службы в Azure Stack Hub, которые взаимодействуют с поставщиками удостоверений, регистрируются как приложения с поставщиком удостоверений.Services in Azure Stack Hub that interact with the identity provider are registered as apps with the identity provider. Как и в случае с приложениями, регистрация позволяет службе выполнить проверку подлинности с помощью системы идентификации.Like apps, registration enables a service to authenticate with the identity system.

Все службы Azure используют протоколы OpenID Connect и JSON Web Tokens для идентификации.All Azure services use OpenID Connect protocols and JSON Web Tokens to establish their identity. Благодаря согласованному использованию протоколов службами Azure AD и AD FS вы можете использовать библиотеку проверки подлинности Azure Active Directory ADAL, чтобы выполнить проверку подлинности в локальной среде или в Azure (с подключением к Интернету).Because Azure AD and AD FS use protocols consistently, you can use Azure Active Directory Authentication Library (ADAL) to authenticate on-premises or to Azure (in a connected scenario). С помощью ADAL также можно использовать такие средства, как Azure PowerShell и Azure CLI, для управления ресурсами в локальной среде и в нескольких облаках.With ADAL, you can also use tools such as Azure PowerShell and Azure CLI for cross-cloud and on-premises resource management.

Удостоверения и система идентификацииIdentities and your identity system

К удостоверениям для Azure Stack Hub относятся учетные записи пользователей, группы и субъекты-службы.Identities for Azure Stack Hub include user accounts, groups, and service principals.

При установке Azure Stack Hub несколько встроенных приложений и служб автоматически регистрируются в поставщике удостоверений в клиенте каталога.When you install Azure Stack Hub, several built-in apps and services automatically register with your identity provider in the directory tenant. Некоторые регистрируемые службы используются для администрирования.Some services that register are used for administration. Другие службы доступны для пользователей.Other services are available for users. При стандартной регистрации основные службы получают удостоверения, которые могут взаимодействовать между собой и с удостоверениями, которые будут добавлены позже.The default registrations give core services identities that can interact both with each other and with identities that you add later.

Если вы настроили Azure AD с поддержкой мультитенантности, некоторые приложения распространяются в новые каталоги.If you set up Azure AD with multi-tenancy, some apps propagate to the new directories.

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

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

Удостоверения между слоями Azure Stack Hub

Для приложений и пользователей архитектура Azure Stack Hub описывается с помощью четырех слоев.For apps and users, the architecture of Azure Stack Hub is described by four layers. При взаимодействии между каждым из этих слоев могут использоваться разные типы проверки подлинности.Interactions between each of these layers can use different types of authentication.

УровеньLayer Проверка подлинности между слоямиAuthentication between layers
Средства и клиенты, например портал администрированияTools and clients, such as the administrator portal Чтобы использовать или изменять ресурсы в Azure Stack Hub, средства и клиенты указывают JSON Web Token при вызове Azure Resource Manager.To access or modify a resource in Azure Stack Hub, tools and clients use a JSON Web Token to place a call to Azure Resource Manager.
Azure Resource Manager проверяет JSON Web Token и просматривает утверждения в выданном маркере, чтобы оценить уровень авторизации пользователя или субъекта-службы в Azure Stack Hub.Azure Resource Manager validates the JSON Web Token and peeks at the claims in the issued token to estimate the level of authorization that user or service principal has in Azure Stack Hub.
Платформа Azure Resource Manager и ее основные службыAzure Resource Manager and its core services Azure Resource Manager взаимодействует с поставщиками ресурсов для передачи данных от пользователей.Azure Resource Manager communicates with resource providers to transfer communication from users.
Для передачи данных используются прямые императивные вызовы или декларативные вызовы через шаблоны Azure Resource Manager.Transfers use direct imperative calls or declarative calls via Azure Resource Manager templates.
Поставщики ресурсовResource providers Вызовы, передаваемые поставщикам удостоверений, защищены проверкой подлинности на основе сертификатов.Calls passed to resource providers are secured with certificate-based authentication.
Azure Resource Manager и поставщик удостоверений затем взаимодействуют с помощью API.Azure Resource Manager and the resource provider then stay in communication through an API. Каждый вызов, полученный из Azure Resource Manager, поставщик удостоверений проверяет с помощью сертификата.For every call that's received from Azure Resource Manager, the resource provider validates the call with that certificate.
Инфраструктура и бизнес-логикаInfrastructure and business logic Поставщики ресурсов взаимодействуют с бизнес-логикой и инфраструктурой с помощью режима проверки подлинности на свой выбор.Resource providers communicate with business logic and infrastructure by using an authentication mode of their choice. Стандартные поставщики удостоверений, которые поставляются с Azure Stack Hub, используют проверку подлинности Windows для защиты этой связи.The default resource providers that ship with Azure Stack Hub use Windows Authentication to secure this communication.

Сведения, необходимые для проверки подлинности

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

Чтобы выполнить проверку подлинности с помощью поставщика удостоверений и получить JSON Web Token, необходимо иметь следующие сведения:To authenticate with the identity provider and receive a JSON Web Token, you must have the following information:

  1. URL-адрес для системы идентификации (Центр) . URL-адрес, по которому можно связаться с поставщиком удостоверений.URL for the identity system (Authority): The URL at which your identity provider can be reached. Например, https://login.windows.net.For example, https://login.windows.net.
  2. URI идентификатора приложения для Azure Resource Manager: уникальный идентификатор для Azure Resource Manager, зарегистрированный с помощью поставщика удостоверений.App ID URI for Azure Resource Manager: The unique identifier for Azure Resource Manager that's registered with your identity provider. Он уникален для каждой установки Azure Stack Hub.It's also unique to each Azure Stack Hub installation.
  3. Учетные данные: подтверждение компетенции, которое вы используете для выполнения проверки подлинности с помощью поставщика удостоверений.Credentials: The credential you use to authenticate with the identity provider.
  4. URL-адрес для Azure Resource Manager: URL-адрес — это расположение службы Azure Resource Manager.URL for Azure Resource Manager: The URL is the location of the Azure Resource Manager service. Например, https://management.azure.com или https://management.local.azurestack.external.For example, https://management.azure.com or https://management.local.azurestack.external.

Когда субъект (клиент, приложение или пользователь) выполняет запрос на проверку подлинности для доступа к ресурсу, запрос должен содержать следующие данные:When a principal (a client, apps, or user) makes an authentication request to access a resource, the request must include:

  • Учетные данные субъекта.The principal's credentials.
  • URI идентификатора приложения для ресурса, к которому субъект хочет получить доступ.The app ID URI of the resource that the principal wants to access.

Учетные данные проверяются поставщиком удостоверений.The credentials are validated by the identity provider. Поставщик удостоверений также проверяет, чтобы URI идентификатора приложения использовался для зарегистрированного приложения и чтобы субъект имел правильные разрешения для получения маркера для ресурса.The identity provider also validates that the app ID URI is for a registered app, and that the principal has the correct privileges to obtain a token for that resource. Если запрос допустимый, предоставляется JSON Web Token.If the request is valid, a JSON Web Token is granted.

Затем маркер передается в заголовке запроса к Azure Resource Manager.The token must then pass in the header of a request to Azure Resource Manager. Azure Resource Manager в любом порядке выполняет следующее:Azure Resource Manager does the following, in no specific order:

  • Проверяет утверждение издателя, чтобы убедиться, что маркер получен из правильного поставщика удостоверений.Validates the issuer (iss) claim to confirm that the token is from the correct identity provider.
  • Проверяет утверждение аудитории, чтобы убедиться, что маркер был выдан Azure Resource Manager.Validates the audience (aud) claim to confirm that the token was issued to Azure Resource Manager.
  • Проверяет, что JSON Web Token подписан с помощью сертификата, настроенного через OpenID, известного для Azure Resource Manager.Validates that the JSON Web Token is signed with a certificate that's configured through OpenID and known to Azure Resource Manager.
  • Просматривает утверждения времени выдачи и окончания срока действия, чтобы убедиться, что маркер активный и может быть принят.Review the issued at (iat) and expiration (exp) claims to confirm that the token is active and can be accepted.

После выполнения всех проверок, Azure Resource Manager использует утверждения идентификатора объекта (oid) и групп для создания списка ресурсов, к которым субъект может получить доступ.When all validations are complete, Azure Resource Manager uses the object id (oid) and the groups claims to make a list of resources that the principal can access.

Схема протокола обмена маркерами

Примечание

После развертывания разрешение глобального администратора Azure Active Directory не требуется.After deployment, Azure Active Directory global administrator permission isn't required. Однако для некоторых операций могут потребоваться учетные данные глобального администратора (например, сценарий установщика поставщика ресурсов или новая функция, требующая предоставления разрешения).However, some operations may require the global admin credentials (for example, a resource provider installer script or a new feature requiring a permission to be granted). Можно временно восстановить разрешения глобального администратора или использовать отдельную глобальную учетную запись администратора, которая является владельцем подписки поставщика по умолчанию.You can either temporarily re-instate the account's global admin permissions or use a separate global admin account that's an owner of the default provider subscription.

Использование контроля доступа на основе ролейUse Role-Based Access Control

Управление доступом на основе ролей (RBAC) в Azure Stack Hub реализовано так же, как и в Microsoft Azure.Role-Based Access Control (RBAC) in Azure Stack Hub is consistent with the implementation in Microsoft Azure. Вы можете управлять доступом к ресурсам путем назначения соответствующей роли RBAC пользователям, группам и приложениям.You can manage access to resources by assigning the appropriate RBAC role to users, groups, and apps. Для получения дополнительных сведений об использовании RBAC в Azure Stack Hub ознакомьтесь со следующими статьями:For information about how to use RBAC with Azure Stack Hub, see the following articles:

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

Сведения об использовании Azure PowerShell для проверки подлинности в Azure Stack Hub см. в статье Подключение к Azure Stack в роли пользователя с помощью PowerShell.Details about using Azure PowerShell to authenticate with Azure Stack Hub can be found at Configure the Azure Stack Hub user's PowerShell environment.

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

Сведения об использовании Azure CLI для проверки подлинности в Azure Stack Hub см. в статье Развертывание и администрирование ресурсов в Azure Stack с помощью Azure CLI.For information about using Azure PowerShell to authenticate with Azure Stack Hub, see Install and configure Azure CLI for use with Azure Stack Hub.

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