使用 AAD 应用程序密钥和服务主体密码之间的身份验证区别 [英] Authentication difference between using AAD app key and Service Principal Password

问题描述

要在 Azure 中运行应用程序，我需要在 Azure AD 中创建一个应用程序和一个相应的服务主体.然后我的应用程序针对这个 App/Principal 对进行身份验证.要进行身份验证，我可以在应用注册中创建一个应用程序密钥，或者我可以在服务主体中创建一个密码(以及其他选项).从实际角度看有什么区别?

例如，无论 $key 是应用程序的密钥还是服务主体的密码，这段代码的运行方式完全相同(从外部):

 $key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force$cred = 新对象 System.Management.Automation.PSCredential($appID, $key)添加-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal

什么时候应该对应用进行身份验证，什么时候应该使用服务主体?

解决方案

首先，让我解释一下为什么它在 Azure AD 中同时具有应用程序和服务主体.以下是 Vittorio Bertocci 对使用 Azure AD for Web App 进行 Mordent Authentication 的解释.

<块引用>

Azure AD 定义了一个新实体，即应用程序，旨在将应用程序描述为一个抽象实体:一个模板，如果你将要.作为开发人员，您使用应用程序.在部署时给定的 Application 对象可以作为蓝图来创建一个ServicePrincipal 表示应用程序的具体实例一个目录.就是那个 ServicePrincipal 用来定义什么该应用程序实际上可以在该特定目标目录中执行，谁可以使用它，它可以访问哪些资源，等等.

请耐心等待再过一会儿，抽象的部分就差不多结束了.主要途径Azure AD 从应用程序创建 ServicePrincipal 是同意.以下是流程的简化描述:假设您在目录 A 中创建一个 Application 对象，提供所有到目前为止，我们在前面的章节中已经讨论过协议坐标.说来自租户 B 的用户导航到应用程序的页面并触发身份验证流程.Azure AD 对来自 B 的用户进行身份验证它的主目录 B.这样做时，它发现没有B 中应用的 ServicePrincipal；因此，它会提示用户他或她是否愿意同意该应用访问目录 B(稍后你会看到它的容量).如果用户授予同意，Azure AD 使用 A 中的 Application 对象作为蓝图在 B 中创建一个 ServicePrincipal.除此之外，B 还记录了当前用户同意使用此应用程序(稍后会详细说明).完成后，用户会收到一个用于访问应用程序的令牌.

如果你想知道 Azure AD App key 和 service principal Password 的区别，你最好知道 Application 和 service principal 的关系.我将在此处复制并粘贴

总结

现在，我们可以知道 Azure AD 应用程序密钥和服务原理密码之间的区别了.它们属于不同的对象.要与服务主体关联的密码.这仅适用于应用程序租户登录 azure.但是，您可以提供带有应用程序 ID 的 App 键值，以使用所有租户作为应用程序登录.

要查看有关 Azure Active Directory 中的应用程序和服务主体对象的更多详细信息，您可以参考 本文档.

To run applications in Azure, I need to create an Application in Azure AD and a corresponding Service Principal. Then my application authenticates against this App/Principal pair. To authenticate, I can create an application key in the App registration, or I can create a password in the Service Principal (among other options). What's the difference from a practial standpoint?

For example, this code runs exactly the same (from the outside) whether the $key is the App's key or the Service Principal's password:

    $key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force
    $cred = New-Object System.Management.Automation.PSCredential($appID, $key)
    Add-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal

When should I authenticate against the App, and when should I use the Service Principal?

解决方案

First, let me explain why it has both Applications and service principals in Azure AD. Here is the explanation from Mordent Authentication with Azure AD for Web App by Vittorio Bertocci.

Azure AD defines a new entity, the Application, which is meant to describe an application as an abstract entity: a template, if you will. As a developer, you work with Applications. At deployment time a given Application object can be used as a blueprint to create a ServicePrincipal representing a concrete instance of an application in a directory. It’s that ServicePrincipal that is used to define what the app can actually do in that specific target directory, who can use it, what resources it has access to, and so on.

Bear with me just a little longer, the abstract part is almost over. The main way through which Azure AD creates a ServicePrincipal from an Application is consent. Here’s a simplified description of the flow: Say that you create an Application object in directory A, supplying all the protocol coordinates we’ve discussed so far in earlier chapters. Say that a user from tenant B navigates to the app’s pages and triggers an authentication flow. Azure AD authenticates the user from B against its home directory, B. In so doing, it sees that there is no ServicePrincipal for the app in B; hence, it prompts the user about whether he or she wants to consent for that app to have access to the directory B (you’ll see later in what capacity). If the user grants consent, Azure AD uses the Application object in A as a blueprint for creating a ServicePrincipal in B. Along with that, B records that the current user consented to the use of this application (expect lots of details on this later on). Once that’s done, the user receives a token for accessing the app.

If you want to know the difference between Azure AD App key and service principle Password, you'd better know the relationship of Application and service principal. I will copy&paste here some extracts from this page of the documentation

1. When you register an Azure AD application in the Azure portal, two objects are created in your Azure AD tenant: an application object, and a service principal object.

2. Consider the application object as the global representation of your application for use across all tenants, and the service principal as the local representation for use in a specific tenant. The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects.

3. An application object therefore has a 1:1 relationship with the software application, and a 1:many relationships with its corresponding service principal object(s).A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant.

Example diagram

Summary

Now, we can know the difference between Azure AD App key and service principle password. They belong to different objects. The password to be associated with the service principal. This is just for the application tenant to login azure. However, you can provide the App key value with the application ID to log in as the application with all tenants.

To see more details about Application and service principal objects in Azure Active Directory , you can refer to this document.

这篇关于使用 AAD 应用程序密钥和服务主体密码之间的身份验证区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！