Hello! In our last lesson, we built a decision framework for choosing the right integration technology for a given scenario. You learned when to use Webhooks for notifications, Service Bus for reliable decoupling, Logic Apps for orchestration, and Custom Connectors for API consumption.
Now that we know which tool to use, this lesson will focus on how to secure the communication channels between them. Your learning outcome is to secure API calls between Power Platform and Azure using Azure AD app registrations and managed identities.
Mastering these authentication patterns is fundamental for any professional Power Platform developer. It ensures your integrations are robust, secure, and compliant with enterprise security standards—a core theme of the PL-400 certification. We will cover two primary methods: the traditional approach using App Registrations and the modern, preferred method using Managed Identities.
1. The Foundation: Securing API Calls with Azure AD App Registrations
When an application that isn't a user (like a background service or an external server) needs to access a protected API like the Dataverse Web API, it needs its own identity. The standard way to achieve this in Azure is with an App Registration.
Think of an App Registration as creating a digital passport for your application. This passport has a unique ID (the Client ID) and a secret key. Your application presents these credentials to Azure Active Directory (Azure AD) to prove its identity and receive an access token, which it then uses to call the target API.
Your extensive experience with Dynamics 365 means you've certainly worked with Application Users. This section will connect that concept to the underlying Azure AD configuration.
The Process in Practice
Let's walk through the end-to-end flow of setting this up. The following blog post provides a clear, step-by-step tutorial.
Azure App Registration Guide for Power Platform Integration
This guide from Pozure provides a detailed walkthrough of creating an App Registration for Power Platform API access. We will focus on the core setup steps.
Please read through 'Step 1: Access Azure Portal and Create New App Registration', 'Step 2: Configure Basic App Registration Settings', 'Step 3: Generate Client Secret for Authentication', and 'Step 4: Configure API Permissions for Dataverse Access'. Finally, review 'Step 5: Configure Power Platform Application User'. As you read, focus on how each step contributes to creating a secure, non-user identity for an application.
To summarize and solidify the key steps from that guide:
- Create App Registration in Azure AD: This creates the application's identity in your tenant. You get a unique Application (client) ID.
- Generate a Client Secret: This is the application's password. It's crucial to copy this value immediately and store it securely (ideally in Azure Key Vault), as you cannot retrieve it later. In a professional DevOps pipeline, this secret would be managed as a protected variable.
- Grant API Permissions: You must specify what APIs this application is allowed to call. For Dataverse, you grant the
user_impersonationpermission under the Dynamics CRM API. This permission allows the application to act on behalf of a user, which in this server-to-server context, is the Application User you'll create next. You must also grant Admin Consent for these permissions to become active. - Create Application User in Dataverse: In the Power Platform Admin Center, you create a new Application User and link it to the App Registration by providing its Client ID.
- Assign Security Role: Once the Application User exists in Dataverse, you assign it a Security Role, just like a regular user. This is critical as it defines exactly what tables and operations the application is permitted to perform within that environment.
To see this process in action, the following video demonstrates configuring Postman to authenticate with Dataverse using an App Registration, which is a common way to test API integrations.
PL-400 Exam Prep: Authenticating into the Microsoft Dataverse Web API
This PL-400 prep video by CRM Chap shows how to configure Postman to get an access token for the Dataverse Web API using an OAuth 2.0 flow with an App Registration. This visualizes the concepts from the article.
Watch from the beginning (00:53) to the end of the 'who am I' request demo (10:26). Pay attention to how the Client ID from the App Registration and the Dataverse URL are used in Postman's environment, and how the OAuth 2.0 authorization flow results in an access token.
While App Registrations are effective, they come with a significant drawback: you are responsible for managing the client secret. You have to secure it, rotate it before it expires, and ensure it's not accidentally committed to a source control repository. This management overhead introduces risk.
2. The Modern Approach: Securing APIs with Managed Identities
To solve the problem of credential management, Azure provides Managed Identities. A Managed Identity gives an Azure resource (like an Azure Function, Logic App, or VM) an identity in Azure AD without you having to manage any credentials in your code. Azure handles the authentication, including the rotation of secrets, automatically and seamlessly behind the scenes.
This is the recommended approach for any integration where one Azure service needs to call another.
Deep Dive into Managed Identities
To fully grasp this powerful concept, we'll turn to an excellent deep-dive video. Given your technical background, you'll appreciate the level of detail here.
Microsoft Azure Managed Identity Deep Dive
This video from John Savill's Technical Training is a comprehensive overview of Managed Identities. We'll watch it in segments to break down the key concepts.
First, watch the introduction (00:00 - 02:28) to understand the core problem that Managed Identities solve. Then, watch the sections explaining the two types: System-Assigned (10:14 - 13:25) and User-Assigned (13:25 - 18:11). Focus on the differences in their lifecycle and use cases.
Let's recap the two types of Managed Identities:
-
System-Assigned Managed Identity:
- Created as part of an Azure resource.
- Its lifecycle is tied directly to that resource. If you delete the resource (e.g., an Azure Function), its identity is also deleted.
- There is a one-to-one relationship between the resource and the identity.
- Use case: A specific Azure Function needs access to a specific Key Vault.
-
User-Assigned Managed Identity:
- Created as a standalone Azure resource.
- It has its own independent lifecycle.
- It can be assigned to one or more Azure resources.
- Use case: You have a fleet of 10 VMs that all need the same permissions to access a storage account. You create one User-Assigned identity, grant it the required permissions, and then assign that identity to all 10 VMs.
Now, let's see it in practice.
Microsoft Azure Managed Identity Deep Dive
Continuing with the same video, let's see how a resource uses its managed identity to authenticate and access other Azure resources without any credentials.
Watch the demonstration from 27:08 to 41:16. Observe how the PowerShell script running on the VM simply requests a connection (using Connect-AzAccount -Identity) and is able to access both a Storage Account and Key Vault based on the permissions assigned to its System-Assigned and User-Assigned identities. Notice that no secrets or keys are present in the script.
Managed Identities in a Power Platform Context
So, how does this apply directly to Power Platform?
Scenario 1: An Azure Resource Calling Dataverse
This is a very common pattern. Imagine an Azure Function that needs to query Dataverse.
- You enable a Managed Identity (System- or User-Assigned) on your Azure Function.
- This creates a Service Principal in Azure AD for your function.
- In the Power Platform Admin Center, you create an Application User, just as you did for the App Registration. However, instead of providing the Client ID of an App Registration, you provide the Client ID of the Managed Identity's Service Principal.
- You assign a Security Role to this new Application User in Dataverse.
- Now, your Azure Function code can acquire a token for Dataverse using its managed identity and make API calls without managing any secrets.
Scenario 2: A Dataverse Plug-in Calling an Azure Resource
This is a more advanced and powerful feature directly relevant to the PL-400 exam. Previously, if your C# plug-in needed to access, say, Azure Key Vault, you had to store the connection details somewhere insecurely or in a custom configuration entity. Now, you can use a managed identity.
The process is more complex and involves establishing a federated trust. We won't go through the full implementation, but it's important to understand the concept.
Set up managed identity for Power Platform - Dataverse ...
This Microsoft Learn article describes the new capability of using managed identities within Dataverse plug-ins. It's a technical document, but focus on understanding the high-level steps.
Read the introduction to understand the feature. Then, skim the sections 'Create a new app registration or user-assigned managed identity', 'Create and register Dataverse plug-ins...', 'Create managed identity record in Dataverse', and 'Grant access to the Azure resources...'. The key takeaway is that you associate a managed identity with your plug-in assembly in Dataverse, which allows your C# code to use the IManagedIdentityService to get a token for Azure resources without credentials.
This credential-less pattern for plug-ins is a significant leap forward for security and aligns with modern cloud development practices.
3. Choosing the Right Authentication Method
Your choice between an App Registration and a Managed Identity depends almost entirely on where the calling application is running.
| Method | Security | Management | When to Use |
|---|---|---|---|
| App Registration | Good (with secret rotation and Key Vault) | High (manual credential management) | For applications running outside of Azure (e.g., on-premises servers, third-party SaaS, desktop clients) calling a Power Platform or Azure API. |
| Managed Identity | Excellent | None (Azure manages credentials) | For Azure resources (Functions, Logic Apps, VMs, etc.) calling other Azure AD-protected services (like Dataverse). This is the strongly preferred method for Azure-to-Azure communication. |
Test your understanding!
For each scenario below, state whether you would use an App Registration or a Managed Identity. If you choose Managed Identity, specify whether System-Assigned or User-Assigned would be more appropriate.
Scenario 1: A third-party financial application, hosted in a different cloud provider's data center, needs to push daily transaction summaries into a Dataverse table.
Scenario 2: You are building an Azure Logic App that will run on a schedule, query an Azure SQL Database for new orders, and create corresponding records in Dataverse.
Scenario 3: Your team is deploying a suite of 15 Azure Functions as part of a microservices architecture. All 15 functions require permission to read secrets from a central Azure Key Vault.
Scenario 4: A C# plug-in registered on the Update message of the Contact entity in Dataverse needs to call an Azure Function to perform a complex address validation.
Show answer
Scenario 1: App Registration
- Reasoning: The calling application is external to Azure. Therefore, it cannot have an Azure Managed Identity. You must create an App Registration and provide the client credentials to the third-party application developers.
Scenario 2: Managed Identity (System-Assigned)
- Reasoning: The integration is between two Azure services (Logic App and Azure SQL/Dataverse). A Managed Identity is the best practice. Since the identity is only for this specific Logic App, a System-Assigned identity is the simplest and most direct choice. Its lifecycle is tied to the Logic App itself.
Scenario 3: Managed Identity (User-Assigned)
- Reasoning: You have multiple Azure resources (15 Functions) that need the same set of permissions. Instead of creating 15 separate System-Assigned identities and granting permissions 15 times, it's far more efficient to create a single User-Assigned Managed Identity. You grant permissions to this one identity and then assign it to all 15 Functions.
Scenario 4: Managed Identity
- Reasoning: This is a perfect use case for the Power Platform Managed Identity feature. You would associate a managed identity with the plug-in assembly, allowing your C# code to obtain a token for the Azure Function securely without any hardcoded keys or credentials.
Conclusion
In this lesson, you've learned the two fundamental mechanisms for securing programmatic access between applications and the Power Platform.
Key Takeaways:
- App Registrations provide an identity for applications but require you to manually manage secrets or certificates. They are necessary for applications running outside of the Azure ecosystem.
- Managed Identities are the modern, secure, and preferred method for authentication between Azure resources, including Power Platform. They eliminate the need for developers to handle credentials.
- System-Assigned identities are for single resources, while User-Assigned identities are for granting shared permissions to groups of resources.
- Always choose a Managed Identity over an App Registration when your code is running within a supported Azure service.
What's Next?
With a solid understanding of both integration patterns and security, we are now equipped to tackle a complete end-to-end scenario. In our next lesson, we will design and implement a pattern for synchronizing data between Dataverse and an external Azure SQL database. This will require you to apply the principles of both choosing an integration technology and securing it correctly.