Azure Active Directory應用程序和服務主體

Question

Azure Active Directory具有很好的應用程序和服務主體概念，可以作為應用程序進行身份驗證，例如CI平台或SaaS應用程序。

現在有多種方法可以創建類似於使用cmdlet的MSOL ：

New-MsolServicePrincipal -DisplayName "My new API app" -Type password -Value $myClientSecret

這完全正常（在我使用Add-MsolRoleMember將一些角色分配給服務主體后，我可以訪問Graph API）。 但我還是有一些問題：

1. 為什么此cmdlet不需要首先創建應用程序？
2. 此cmdlet是否同時創建 - 應用程序和服務主體？
3. 為什么我既沒有在經典也沒有新的天藍色門戶中看到應用程序？

也許有人可以回答我第四個問題：上面的MSOL cmdlet和New-AzureRmADApplication + New-AzureRmADServicePrincipal cmdlet有什么New-AzureRmADServicePrincipal ？ 我應該什么時候使用它們？

Answer 1

1和2 - 可能是在租戶中使用現有的Office 365應用程序（我相信它是隱藏的）？

3 - 由於您創建了服務主體，因此需要查看Azure門戶中的enterprise applications以查看租戶中的服務主體對象（而不是應用程序選項卡）。

4 - 這個鏈接

應用對象
Azure AD應用程序由其唯一的應用程序對象定義，該應用程序對象位於注冊了應用程序的Azure AD租戶中，稱為應用程序的“主”租戶。 應用程序對象為應用程序提供與身份相關的信息，並且是從中派生其對應的服務主體對象以供在運行時使用的模板。

將應用程序對象視為應用程序的全局表示（用於所有租戶），將服務主體視為本地表示（用於特定租戶）。 Azure AD Graph Application實體定義應用程序對象的架構。 因此，應用程序對象與軟件應用程序具有1：1的關系，並且與其對應的n個服務主體對象具有1：n的關系。

服務主體對象
服務主體對象定義應用程序的策略和權限，為在運行時訪問資源時表示應用程序的安全主體提供基礎。 Azure AD Graph ServicePrincipal實體定義服務主體對象的模式。

在Azure AD租戶允許應用程序訪問其正在保護的資源之前，必須在給定租戶中創建服務主體。 服務主體為Azure AD提供了基礎，以保護應用程序訪問該租戶的用戶所擁有的資源。 單租戶應用程序將只有一個服務主體（在其租戶中）。 多租戶Web應用程序還將在每個租戶中擁有服務主體，其中來自該租戶的管理員或用戶已經同意，允許其訪問其資源。 經過同意，將咨詢服務主體對象以用於將來的授權請求。

Answer 2

ARM cmdlet和新的Azure AD v2 cmdlet都使用Azure AD Graph API。

但是， New-MsolServicePrincipal不會。 它使用SOAP調用https://provisioningapi.microsoftonline.com/provisioningwebservice.svc 。 它是一個遺留API，您不應該使用它。

服務主體必須始終具有appId ，即創建它的應用程序的客戶端ID。

字段appOwnerTenantId標識應用程序來自哪個租戶。 它可以為null 。 這是MS內部應用程序的情況，例如Graph API，Azure門戶等。但也是使用New-MsolServicePrincipal創建的服務主體，並省略了appId 。

因此，問題1和問題2的答案是：如果未指定應用程序，則會自動創建應用程序。 但我不確定它的創建位置，因為它不能通過Graph API獲得。 這是一個純粹的服務標識。 appId每次都不同，所以不只是使用一些占位符應用程序。

至於問題3：你沒有在門戶中看到應用程序的原因是因為它不能通過Graph API獲得，它隱藏在某個地方。 對於服務主體，主體需要一個非常具體的魔術標記才能顯示在企業應用程序列表中。 和AFAIK，您不能使用New-MsolServicePrincipal或New-AzureRmADServicePrincipal指定它。

第四個問題的答案是MSOL cmdlet使用舊版API，而兩個較新的選項使用Azure AD Graph API。 ARM cmdlet創建一個可以在Portal中看到的應用程序。 他們仍然創建一個您在企業應用程序列表中看不到的。

在創建沒有應用程序的服務主體時，不同cmdlet的行為有所不同：

1. New-MsolServicePrincipal：使用某種隱藏應用程序創建主體，類似於MS內部應用程序（ 也設置servicePrincipalType = Legacy ）
2. New-AzureRmADServicePrincipal：為您創建一個應用程序，然后創建服務主體（該應用程序在Portal中可見，但主體只能通過應用程序的刀片顯示，因為缺少標記）
3. New-AzureADServicePrincipal：不允許您在不提供appId的情況下創建它

如果您希望主體顯示在企業應用程序列表中，就像您通過門戶創建它一樣，則可以使用v2 cmdlet提供必需的標記：

New-AzureADServicePrincipal -Tags @("WindowsAzureActiveDirectoryIntegratedApp") -AppId ed5fa582-3991-4114-87da-30081c4105fb

在我看來，新的v2 cmdlet是最好的，至少它們允許您以類似於Portal的方式創建服務主體。 如果您的目的是為在ARM API中使用RBAC創建服務標識，則ARM cmdlet很好，因為主體可見 。