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 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.
It’s not 100%, but it’s getting there.
How it is
The Power Platform breaks with this entire model, doesn’t offer any delegation functionality.
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.
A solution to address this situation in Power Automate is to use Logic Apps and functions. To work with these, you need create a custom connector, or you could create an app registration in Azure AD (with a service principal, an accompanying secret and permissions). It brings the challenge of having to rotate the secrets periodically.