Azure Stack 的标识概述Overview of identity for Azure Stack

Azure Stack 要求使用 Active Directory 所支持的 Azure Active Directory (Azure AD) 或 Active Directory 联合身份验证服务 (AD FS) 作为标识提供者。Azure Stack requires Azure Active Directory (Azure AD) or Active Directory Federation Services (AD FS), backed by Active Directory as an identity provider. 提供者的选择是首次部署 Azure Stack 时做出的一次性决定。The choice of a provider is a one-time decision that you make when you first deploy Azure Stack. 本文中的概念和授权详细信息可帮助你选择适当的标识提供者。The concepts and authorization details in this article can help you choose between identity providers.

选择 Azure AD 还是 AD FS 取决于 Azure Stack 的部署模式:Your choice of either Azure AD or AD FS is determined by the mode in which you deploy Azure Stack:

  • 在连接模式下部署时,可以使用 Azure AD 或 AD FS。When you deploy it in a connected mode, you can use either Azure AD or AD FS.
  • 在未建立 Internet 连接的离线模式下部署时,仅支持 AD FS。When you deploy it in a disconnected mode, without a connection to the internet, only AD FS is supported.

若要详细了解依赖于 Azure Stack 环境的选项,请参阅以下文章:For more information about your options, which depend on your Azure Stack environment, see the following articles:

标识的一般概念Common concepts for identity

后续部分介绍标识提供者的一般概念及其在 Azure Stack 中的用法。The next sections discuss common concepts about identity providers and their use in Azure Stack.

标识提供者的术语

目录租户和组织Directory tenants and organizations

目录是保留用户、应用程序、组和服务主体相关信息的容器。 A directory is a container that holds information about users, applications, groups, and service principals.

目录租户是一个组织,例如 Azure 或你自己的公司。 A directory tenant is an organization, such as Azure 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 applications 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

用户帐户(标识)是标准帐户,可使用用户 ID 和密码对个人进行身份验证。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 中,用户帐户:In Azure Stack, user accounts:

  • username@domain 格式创建。Are created in the username@domain format. 尽管 AD FS 可将用户帐户映射到 Active Directory 实例,但 AD FS 不支持使用 \<域>\<别名> 格式。Although AD FS maps user accounts to an Active Directory instance, AD FS does not 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.

登录到组织的租户门户时,请使用 https://portal.local.azurestack.external URL。When you sign in to your organization's tenant portal, you use the https://portal.local.azurestack.external URL. 从用于注册 Azure Stack 的域以外的域登录 Azure Stack 门户时,用于注册 Azure Stack 的域名必须追加到门户 URL 后面。When signing into the Azure Stack portal from domains other than the one used to register Azure Stack, the domain name used to register Azure Stack must be appended to the portal url. 例如,如果 Azure Stack 已注册到 fabrikam.partner.onmschina.cn 并且登录的用户帐户为 admin@contoso.com,则用于登录用户门户的 URL 将为 https://portal.local.azurestack.external/fabrikam.partner.onmschina.cn。For example, if Azure Stack has been registered with fabrikam.partner.onmschina.cn 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.partner.onmschina.cn.

来宾用户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.

可以作为来宾用户登录到其他组织的目录租户。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 目录,可以使用 https://portal.local.azurestack.external/fabrikam.partner.onmschina.cn。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.partner.onmschina.cn.

应用程序Applications

可以向 Azure AD 或 AD FS 注册应用程序,然后将应用程序提供给组织中的用户。You can register applications to Azure AD or AD FS, and then offer the applications to users in your organization.

应用程序包括:Applications include:

  • Web 应用程序:示例包括 Azure 门户和 Azure 资源管理器。Web application: Examples include the Azure portal and Azure Resource Manager. 它们支持 Web API 调用。They support Web API calls.
  • 本机客户端:示例包括 Azure PowerShell、Visual Studio 和 Azure CLI。Native client: Examples include Azure PowerShell, Visual Studio, and Azure CLI.

应用程序可支持两种租户:Applications can support two types of tenancy:

  • 单租户:仅支持应用程序注册时所在的目录中的用户和服务。Single-tenant: Supports users and services only from the same directory where the application is registered.

    Note

    由于 AD FS 仅支持单个目录,因此在 AD FS 拓扑中创建的应用程序设计为单租户应用程序。Because AD FS supports only a single directory, applications you create in an AD FS topology are, by design, single-tenant applications.

  • 多租户:支持应用程序注册时所在目录以及其他租户目录中的用户和服务使用。Multi-tenant: Supports use by users and services from both the directory where the application is registered and additional tenant directories. 另一个租户目录(另一个 Azure AD 租户)的用户可以使用多租户应用程序登录到应用程序。With multi-tenant applications, users of another tenant directory (another Azure AD tenant) can sign in to your application.

    有关多租户的详细信息,请参阅启用多租户For more information about multi-tenancy, see Enable multi-tenancy.

    有关如何开发多租户应用的详细信息,请参阅多租户应用For more information about developing a multi-tenant app, see Multi-tenant apps.

注册应用程序时,请创建两个对象:When you register an application, you create two objects:

  • 应用程序对象:应用程序在所有租户中的全局表示形式。Application object: The global representation of the application across all tenants. 此关系是与软件应用程序的一对一关系,且只存在于应用程序首先注册到的目录中。This relationship is one-to-one with the software application and exists only in the directory where the application is first registered.

  • 服务主体对象:在首先注册应用程序的目录中针对应用程序创建的凭据。Service principal object: A credential that is created for an application in the directory where the application is first registered. 服务主体也是在使用该应用程序的其他每个租户的目录中创建的。A service principal is also created in the directory of each additional tenant where that application is used. 此关系可以是与软件应用程序的一对多关系。This relationship can be one-to-many with the software application.

有关应用程序和服务主体的详细信息,请参阅 Azure Active Directory 中的应用程序和服务主体对象To learn more about application and service principal objects, see Application and service principal objects in Azure Active Directory.

服务主体Service principals

服务主体是应用程序或服务的一组凭据,可授予 Azure Stack 中资源的访问权限。 A service principal is a set of credentials for an application or service that grant access to resources in Azure Stack. 使用服务主体可将应用程序权限与应用程序用户权限区分开来。The use of a service principal separates the application permissions from the permissions of the user of the application.

服务主体是在使用应用程序的每个租户中创建的。A service principal is created in each tenant where the application 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 application has only one service principal, in the directory where it is first created. 此服务主体在应用程序注册期间创建并允许用户使用。This service principal is created and consents to being used during registration of the application.
  • 多租户 Web 应用程序或 API 将在每个租户中创建一个服务主体,前提是该租户的用户同意使用此应用程序。A multi-tenant web application or API has a service principal that's created in each tenant where a user from that tenant consents to the use of the application.

服务主体的凭据可以是通过 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.

Note

在 Azure Stack 中使用 AD FS 时,只有管理员可以创建服务主体。When you use AD FS with Azure Stack, only the administrator can create service principals. 使用 AD FS 时,服务主体需要证书,并需要通过特权终结点 (PEP) 来创建。With AD FS, service principals require certificates and are created through the privileged endpoint (PEP). 有关详细信息,请参阅提供对 Azure Stack 的应用程序访问权限For more information, see Provide applications access to Azure Stack.

若要了解 Azure Stack 的服务主体,请参阅创建服务主体To learn about service principals for Azure Stack, see Create service principals.

服务Services

Azure Stack 中与标识提供者交互的服务,标识提供者将其注册为应用程序。Services in Azure Stack that interact with the identity provider are registered as applications with the identity provider. 如同应用程序,注册可让服务在标识系统中进行身份验证。Like applications, registration enables a service to authenticate with the identity system.

所有 Azure 服务都使用 OpenID Connect 协议和 JSON Web 令牌来建立其标识。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 的标识包括用户帐户、组和服务主体。Identities for Azure Stack include user accounts, groups, and service principals.

当安装 Azure Stack 时,有多个内置应用程序和服务在目录租户中自动向标识提供者注册。When you install Azure Stack, several built-in applications 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 applications propagate to the new directories.

身份验证和授权Authentication and authorization

应用程序和用户的身份验证Authentication by applications and users

Azure Stack 层之间的标识

对应用程序和用户而言,Azure Stack 的体系结构可以用四个层来描述。For applications and users, the architecture of Azure Stack 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 Admin portal 为了访问或修改 Azure Stack 中的资源,工具和客户端将使用 JSON Web 令牌来调用 Azure 资源管理器。To access or modify a resource in Azure Stack, tools and clients use a JSON Web Token to place a call to Azure Resource Manager.
Azure 资源管理器验证 JSON Web 令牌并扫视所颁发令牌中的声明,以评估用户或服务主体在 Azure Stack 中的授权级别。 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.
Azure 资源管理器及其核心服务Azure Resource Manager and its core services Azure 资源管理器与资源提供程序通信,以传输用户的通信。Azure Resource Manager communicates with resource providers to transfer communication from users.
传输通过 Azure 资源管理器模板使用直接命令式调用或声明式调用。 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 资源管理器和资源提供程序持续通过 API 通信。Azure Resource Manager and the resource provider then stay in communication through an API. 对于从 Azure 资源管理器 收到的每个调用,资源提供程序使用该证书来验证调用。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 随附的默认资源提供程序使用 Windows 身份验证来保护此通信。The default resource providers that ship with Azure Stack use Windows Authentication to secure this communication.

身份验证所需的信息

对 Azure 资源管理器进行身份验证Authenticate to Azure Resource Manager

若要在标识提供者中进行身份验证并接收 JSON Web 令牌,必须提供以下信息: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.chinacloudapi.cnFor example, https://login.chinacloudapi.cn.
  2. Azure 资源管理器的应用 ID URI:已向标识提供者注册的 Azure 资源管理器的唯一标识符,App ID URI for Azure Resource Manager: The unique identifier for Azure Resource Manager that is registered with your identity provider. 也是每个 Azure Stack 安装中的唯一标识符。It is also unique to each Azure Stack installation.
  3. 凭据:用于在标识提供者中进行身份验证的凭据。Credentials: The credential you use to authenticate with the identity provider.
  4. Azure 资源管理器 的 URL:该 URL 是 Azure 资源管理器服务的位置。URL for Azure Resource Manager: The URL is the location of the Azure Resource Manager service. 例如,https://management.chinacloudapi.cnhttps://management.local.azurestack.externalFor example, https://management.chinacloudapi.cn or https://management.local.azurestack.external.

当主体(客户端、应用程序或用户)发出访问资源所需的身份验证请求时,该请求必须包含:When a principal (a client, application, or user) makes an authentication request to access a resource, the request must include:

  • 主体的凭据。The principal's credentials.
  • 主体想要访问的资源的应用 ID URI。The app ID URI of the resource that the principal wants to access.

凭据已由标识提供者验证。The credentials are validated by the identity provider. 标识提供者还会验证应用 ID URI 是否用于已注册的应用程序,以及主体是否拥有适当的权限,可获取该资源的令牌。The identity provider also validates that the app ID URI is for a registered application, and that the principal has the correct privileges to obtain a token for that resource. 如果请求有效,则授予 JSON Web 令牌。If the request is valid, a JSON Web Token is granted.

然后,必须将此令牌传入发往 Azure 资源管理器的请求的标头中。The token must then pass in the header of a request to Azure Resource Manager. Azure 资源管理器执行以下操作(不遵循特定的顺序):Azure Resource Manager does the following, in no specific order:

  • 验证 issuer (iss) 声明,确认令牌来自正确的标识提供者。Validates the issuer (iss) claim to confirm that the token is from the correct identity provider.
  • 验证 audience (aud) 声明,确认令牌已颁发给 Azure 资源管理器。Validates the audience (aud) claim to confirm that the token was issued to Azure Resource Manager.
  • 验证 JSON Web 令牌是否已使用通过 OpenID 配置的证书进行签名,并且为 Azure 资源管理器所知。Validates that the JSON Web Token is signed with a certificate that is configured through OpenID is known to Azure Resource Manager.
  • 检查 issued at (iat) 和 expiration (exp) 声明,确认令牌处于活动状态并且可以接受。Review the issued at (iat) and expiration (exp) claims to confirm that the token is active and can be accepted.

完成所有验证后,Azure 资源管理器使用 objected (oid) 和 groups 声明来生成主体可以访问的资源列表。When all validations are complete, Azure Resource Manager uses the objected (oid) and the groups claims to make a list of resources that the principal can access.

令牌交换协议示意图

Note

部署后,不需要 Azure Active Directory 全局管理员权限。After deployment, Azure Active Directory global administrator permission is not required. 但是,某些操作可能需要全局管理员凭据。However, some operations may require the global administrator credential. 例如,资源提供程序安装程序脚本或需要授予权限的新功能。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 administrator permissions or use a separate global administrator account that is an owner of the default provider subscription.

使用基于角色的访问控制Use Role-Based Access Control

Azure Stack 中基于角色的访问控制 (RBAC) 与 Azure 中的实现一致。Role-Based Access Control (RBAC) in Azure Stack is consistent with the implementation in Azure. 可以通过将相应的 RBAC 角色分配给用户、组和应用程序,来管理资源访问权限。You can manage access to resources by assigning the appropriate RBAC role to users, groups, and applications. 有关如何在 Azure Stack 中使用 RBAC 的信息,请参阅以下文章:For information about how to use RBAC with Azure Stack, see the following articles:

使用 Azure PowerShell 进行身份验证Authenticate with Azure PowerShell

有关使用 Azure PowerShell 在 Azure Stack 中进行身份验证的详细信息,请参阅配置 Azure Stack 用户的 PowerShell 环境Details about using Azure PowerShell to authenticate with Azure Stack can be found at Configure the Azure Stack user's PowerShell environment.

使用 Azure CLI 进行身份验证Authenticate with Azure CLI

有关使用 Azure PowerShell 在 Azure Stack 中进行身份验证的信息,请参阅安装和配置与 Azure Stack 配合使用的 Azure CLIFor information about using Azure PowerShell to authenticate with Azure Stack, see Install and configure Azure CLI for use with Azure Stack.

后续步骤Next steps