Recently, I had some experiences with the Power Platform. As an identity guy, I was appalled at what I found as Microsoft’s identity and delegation model for these services. Let me tell you why.
About the Power Platform
Microsoft’s Power Platform consists of four distinct products and services:
- Power BI
Through dashboards, Power BI can present information in a flexible and automatically updated way, based on data from several sources, including Azure databases and Microsoft 365 resources - Power Apps
Based on templates and low code development resources, people in organizations can build their own apps that interact with Microsoft 365 resources. One of the more popular templates was the room booking app. It interacts with room resources in Exchange Online. - Power Automate
Organizational processes can be automated using flow charts that can be triggered manually or run automatically based on triggers to interact with Microsoft 365 services. - Power Virtual Agents
Chatbots can be delivered to have automated conversations with employees and customers.
The four products and services have in common that it requires no coding experience and that you can easily interact with the Microsoft 365 resources and services.
Identity and Delegation within the Power Platform
All this goodness comes with a price: The products and services in the Power Platform that I had experiences with (this excludes Power Virtual Agents) are geared towards increasing personal productivity. Herein lies the problem; it doesn’t have an underpinning identity model that allows for delegation.
When talking about Power Apps and Power Automate, specifically, the Azure AD account that is used to create the apps and flows is configured to be the owner of the resource. To interact with Microsoft 365 resources, the account requires the license to do so. To interact with a calendar, for instance, requires at least the Exchange Online Plan 1 user license. When creating an exclusion in Conditional Access policies and accessing resources in Exchange Online, SharePoint Online and Teams, a Microsoft 365 E3 license soon comes into picture.
This is ideal for personal productivity, but it poses a problem, when the organization publishes the Power App towards the entire organization, the owner of the Power App leaves the organization and, understandably, admins remove the license and/or the Azure AD account of the owner. In these cases, functionality breaks.
Microsoft’s advice
Microsoft empowers every person and every organization on the planet to achieve more and advises to create a separate service account for its Power Platform products and services to avoid the above situation. Organizations have incorporated checks to ensure no organization-wide Power Platform functionality breaks when a person (or consultant) leaves the organization.
How it should be
Azure and Azure AD are mature solutions that include an identity and delegation model that works:
When third-party code runs against Azure or Microsoft 365 resources, a service principal is the way to go. It can’t be used interactively and it can be assigned and/or delegated API permissions.
When Microsoft services interact with other Microsoft services, the managed identity is the way to go. it’s tied to the Microsoft service and can be allowed access to only the Azure and Microsoft 365 resources it needs.
I'll admit this model isn't 100% in place today , but it’s getting there.
How it is
The Power Platform breaks with this entire model. It relies on user accounts for managing things and its delegation capabilities offer only standard functionality.
My opinion
I feel Power Platform’s Identity and Delegation model is out of this world. I feel Microsoft should introduce a mature identity and delegation model that aligns with the other products and services Microsoft offers.
Came here because I was searching for the same thing. It seems there is some improvement going on where at least you can create "app users" within the Power Platform now, which are linked to an app registration in Azure AD. Sounds nice, until you try to use it for for instance Azure AD tasks like "Create a user", which do not seem to have support for this option. I could only find articles only discussing this option for Microsoft Dataverse and other data-driven solutions. But apparently the same has not yet been applied to other types of actions.