Cloud Solution Provider: Pre-consent

  • Article

The Azure Active Directory (AAD) consent framework provides company administrators, and individual users, a mechanism for governing an application’s access to resources. This framework ensures that only authorized applications can access resources that belong to a specific company or user. While the consent framework provides a vital security mechanism it creates two problems for Cloud Solution Providers, who are developing custom integration. In order to better understand the problems let’s consider the following scenario

Scenario

You have a solution that provides customers with the ability to design custom training paths for their employees. Each customer has the ability to upload customized training materials that include lab guides, sample code, and videos. This solution can be implemented in a dedicate environment, or a customer can utilize a multi-tenant deployment of the solution. Both the dedicated and multi-tenant version utilize Azure App Services, Cosmos DB, Media Services, and SharePoint Online to provide the necessary portal and a way to version control documents.

In order to ensure each installation of the solution is deployed in a uniform fashion, Azure Resource Manager (ARM) templates are utilized to create and configure the Azure Resources. Microsoft Graph will be utilized to interact with SharePoint and to obtain various information about the authenticated user such as their display name. When a customer purchases the solution a new customer will be created in Partner Center and an Office 365 subscription will be provisioned. If the customer purchased the dedicated version an Azure subscription will be provisioned, and the resources should be deployed into the region specified by the customer.

Problems

This scenario requires the ability to utilize Microsoft Graph to manage SharePoint documents and read user information. Also, the ARM API is required to create and configure the Azure resources. When attempting to access resources that belong to a specific customer you will be prompted fro consent as shown in the following figure

image

This is where both of the problems with the consent framework (for Cloud Solution Providers) can happen

  1. The customer will not have access to the newly created Azure AD tenant until the entire provisioning process has been completed. Since they will not have access, yet, the company administrator is unable to consent to the application utilized to access the ARM API and Microsoft Graph. This will prevent you from being able to deploy the solution into the customer’s Azure subscription, and the portal will not be able to access the Microsoft Graph on the customer's behalf.
  2. While it is possible to perform an admin consent it is difficult to ensure each customer has performed the operation and that it was done correctly.

Solution

Cloud Solution Providers that have a relationship with the customer can leverage pre-consent in order to address both of these problems. Pre-consent leverages the delegated administrative privileges that are established when a new customer is created, or when a reseller relationship is established, in order to automatically consent to appropriately configured applications. The application in question must be created in the Azure AD tenant associated with the CSP reseller. To configure an application for pre-consent the service principal object associated with the application needs to be added to the AdminAgents group. The following PowerShell cmdlets can be utilized to configure the application

 
Connect-AzureAD
$AppId = 'INSERT-APPLICATION-ID-HERE'
$DisplayName = 'INSERT-APPLICATION-DISPLAY-NAME-HERE'

$g = Get-AzureADGroup | ? {$_.DisplayName -eq 'AdminAgents'}
$s = Get-AzureADServicePrincipal | ? {$_.AppId -eq $AppId}
if ($s -eq $null) { $s = New-AzureADServicePrincipal -AppId $AppId -DisplayName $DisplayName }
Add-AzureADGroupMember -ObjectId $g.ObjectId -RefObjectId $s.ObjectId

Possible Issue

Under certain circumstances you might encounter an error stating “the identity of the calling application cannot be established” when requesting an access token. One possible cause for this error is that the service principal object for the application is missing from the customer’s Azure AD tenant. By design applications that are configured for pre-consent will automatically create a service principal object in the customer’s Azure AD tenant. In rare circumstances the service principal object is not create and this error is thrown. You can correct this error by creating a new service principal object that references the application within the customer’s Azure AD tenant. One way this can be accomplished is by invoking the following PowerShell cmdlets

 
Connect-AzureAD –TenantDomain customer.onmicrosoft.com
$AppId = 'INSERT-APPLICATION-ID-HERE' 
$DisplayName = 'INSERT-APPLICATION-DISPLAY-NAME-HERE'

$s = Get-AzureADServicePrincipal | ? {$_.AppId -eq $AppId}
if ($s -eq $null) { $s = New-AzureADServicePrincipal -AppId $AppId -DisplayName $DisplayName }

Be sure to modify the AppId, DisplyName and tenant domain values accordingly prior to invoking the cmdlets.