使用AAD app密钥和Service Principal Password之间的身份验证差异

Question

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

例如,无论$ key是App的密钥还是Service Principal的密码,此代码都(从外部)运行完全相同:

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

我何时应该对应用程序进行身份验证,何时应该使用服务主体？

Answer 1

首先，让我解释一下为什么它在Azure AD中同时具有应用程序主体和服务主体。这是Vittorio Bertocci的“针对Web App的Azure AD for Web App的Mordent身份验证”的说明。

Azure AD定义了一个新的实体Application，该实体用于将应用程序描述为抽象实体：如果需要，则为模板。作为开发人员，您可以使用“应用程序”。在部署时，给定的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密钥和服务原理密码之间的区别，则最好了解应用程序和服务原理之间的关系。我将在此处复制并粘贴文档此页面的某些摘录

1. 在Azure门户中注册Azure AD应用程序时，将在Azure AD租户中创建两个对象：一个应用程序对象和一个服务主体对象。

2. 将应用程序对象视为在所有租户中使用的应用程序的全局表示形式，并将服务主体视为在特定租户中使用的本地表示形式。应用程序对象用作模板，从该模板派生通用属性和默认属性以用于创建相应的服务主体对象。

3. 因此，应用程序对象与软件应用程序具有1：1关系，与其对应的服务主体对象具有1：1：1关系。必须在使用该应用程序的每个租户中创建服务主体，以使其能够建立租户保护的用于登录和/或访问资源的身份。

示例图

摘要

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

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