Power Platform security considerations

“We can’t just let everyone make apps as they please! How can we make sure who can see and modify information X?”

I hear this (and many other Power Platform security concerns) often. In today’s post, we will dive into the security in Power Platform. More specifically, on the topic of how users access different data in Power Platform solutions.

At the heart of Power Platform are the connectors. They allow solution makers to easily leverage a variety of data sources (SharePoint, Dynamics 365, Salesforce, SQL databases, Google services, etc.). Currently, there are almost 400 connectors and more are being added all the time.

All data retrieval, editing, adding and deleting functions are built using connectors.

Connections

Let’s imagine we have (Canvas) Power Apps with a SharePoint list as the data source. All of the data operations are performed using the SharePoint connector.

What happens when a user launches an application for the first time? They will be asked for permission to use the data sources utilized by the application (using connectors). By giving consent, Power Platform creates the necessary connections with the user’s credentials .

For Office 365 services, this happens automatically. After all, the user is already logged in to Office 365 environment. For example, if the solution uses Salesforce, the user must log in to Salesforce with their own credentials to establish a connection.

In practice, when users 1 and 2 use the application, they have their own connections to all of the utilized data sources, using their own credentials.

The users see exactly the rows of the data source that they are allowed to see. The same applies for adding, editing, and deleting rows.

Everything is always done with the users credentials.

Except…

Shared connections

However, there are a few connectors that work differently. These are using shared connections. A classic example of this is using an Azure SQL database using SQL Server’s login credentials.

In this case, the maker of the application creates the connection and shares it so it’s available for all users of the application.

Here you need to know what you are doing. For example, shared connections in a default environment can be really dangerous.

The maker of the application will be warned about the topic already the development stage.

And also when sharing the application.

Unfortunately, these warnings are often dismissed by citizen developers. They just press Confirm and move on.

Indirect use of connections

On theapp level it is difficult for an Power Apps maker to come up with a solution where users can perform actions which they do not have the rights for. However, this is possible with indirect use of connections.

Let’s take as an example an application that is used to create and edit issues. The maker of the application has created a workflow (Power Automate cloud flow) that immediately copies the issues to another location (archive). End users of the application do not have rights to the entire archive.

The application itself, however, works just as if they all had the rights to create issues in the archive as well.

Indirect use of connections does not happen by accident, but rather it is a conscious decision of the maker. In addition to circumventing access rights, it often also used in multiplexing of licenses.

Read more about this topic in the blog post by Jukka Niiranen: Implicitly shared connections in Power Apps: what’s the risk?

Guest users

Canvas Power Apps can also be shared with tenant guest users.

In this case, what happens to the connections?

Let’s create an application that uses Outlook and SharePoint connectors. The application displays the user’s emails, as well as lists the issues form the SharePoint list.

Let’s distribute the application to a guest user.

When a guest user opens the application for the first time, the necessary connections are established for them.

But where? The message is a bit vague in this regard.

Well, the guest user just gave the app the permission to read the contents of their email (and calendar and tasks), send emails on their behalf etc. on the account in their home tenant.

At least the SharePoint connection points to a SharePoint list in the same tenant as the application.

The cross-use of connectors between tenants can be limited. For now, the feature can be activated through support, but likely it can be configured straight from the interface in the future.

Environments

In addition to connections, another key security element of the Power Platform are the (Power Platform) environments.

All elements of the Power Platform (Power Apps, Flows, Connections, Environment Variables, Dataverse, DLP Rules, etc.) are always located within one environment.

For example, if a user uses Power Apps that utilize a SharePoint connection, and they are located in different environments, each of those environments have their own SharePoint connection.

Each environment can also have (one) Dataverse database. User access management always takes place on the environment level, with settings that depenend on the environment type.

To be able to do anything in the environment, you must:

1. Be a user of the environment
2. Have the necessary security roles and have access to the required information in the environment

By default, the user of an environment cannot create applications and cannot see the contents of the tables in the environment.

In the beginning, it is important to understand that solutions can be compartmentalized into their own environments, and these environments include comprehensive tools for managing access rights and security roles.

It is also important to remember, that a Power Platform environment is not the same thing as the Office 365 tenant or Azure subscriptions / resource groups.

DLP Policies (Data Loss Prevention)

DLP policies can be used to control which connectors are allowed to be used in any given environment. I have written about DLP policies in the past, and recommend to check out the posts below (translated from Finnish) if you are new to the topic:

• Power Platform and DLP policies
• What new was released in Ignite 2021 (ends with highlights of upcoming DLP updates)

In my experience, DLP policies are a very underutilized feature. I recommend thinking about suitable DLP policies right at the beginning of one’s Power Platform implementation.

There are significant features coming to DLP policies in the near future, which will make them even more powerful.

Available IP addresses and services

Power Platform is by nature a service (PaaS , platform as a service). It resides on public network and cannot be used if the IP addresses / services it utilized are blocked.

Information about the IP addresses and services used by Power Apps canvas apps can be found here:

https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/limits-and-config

Same for Power Automate here:

https://docs.microsoft.com/en-us/power-automate/ip-address-configuration

Summary

In canvas Power Apps, all operations related to data sources are performed (with a few known exceptions) with end-user credentials and access rights. There is no cause for concern in this regard.

In addition to this, the Power Platform provides comprehensive mechanisms to limit the use of connectors in different solutions.

And as you move to Dataverse, the quite extensive user and access control features familiar from the world of Dynamics 365 are introduced.