Power Apps Security
As with all the Power Platform tools, Power Apps relies on a layered security model that includes the following elements:
■ Azure Active Directory authentication—Power Apps uses Azure Active Directory (Azure AD) user accounts to control access to its portal and to specific apps. Administrators with appropriate Azure AD credentials can assign Power Apps licenses to users and grant them access to specific apps and security roles. Administrators can also use other Azure tools to regulate access to Power Apps, including conditional access policies and the mobile application protection policies provided by Microsoft Intune.
■ Power Apps licensing—Developers and consumers must possess a Power Apps license to access the portal, create apps, and run apps.
■ Environment security roles—Each environment has two built-in administrative security roles, as follows. To assign users to these roles, administrators use the interface shown in Figure 1-42, found in the Power Apps admin center.
FIGURE 1-42 Assigning the Environment Maker role
- ■ Environment Admin—Can perform all administrative tasks for an environment, including adding users to the Environment Admin and Environment Maker roles, creating Common Data Service databases, and managing all other resources in the environment.
- ■ Environment Maker—Can create resources in the environment, including apps, flows, connections, custom connectors, and gateways, and share apps with other users.
■ App sharing—Developers can choose to share apps with other Azure AD users through the interface shown in Figure 1-43. By default, the selected sharers are standard users of the app, but the developer can also designate them as co-owners. A co-owner of an app can edit it and share it with others but cannot delete the app or change its owner.
FIGURE 1-43 Power Apps Share dialog box
■ Environment boundaries—An environment is a container for apps, flows, and data that is separate from any other environments in the same tenant. A tenancy has a single environment by default, which is named for the tenant. Administrators can create all their apps and flows in that default environment, or they can choose to create additional environments in that tenant to make separate development spaces. For example, administrators can create separate environments for the various teams or departments in the organization, use them to separate testing and production versions of apps, or use them to create spaces with different security requirements. Each environment is created in a selected geographic region, and all of the environment’s resources are bound to that region. If an administrator chooses to create a Common Data Service database in an environment, that database and the data it contains are only available to apps and flows created in that same environment.
■ Connector credentials—The Share dialog box also lists the data connections used by the app. The administrator must see to it that the selected users also have credentials with the permissions required to access the data sources the app needs to function. Power Apps does not provide users with access to data for which they do not already have permissions.
■ Common Data Service user security roles—A Common Data Service database has three standard security roles, which are sets of permissions that administrators can assign to users and groups and which determine what operations the users can perform on database entities. Administrators can also create custom security roles that contain any combination of the following record-level privileges: create, read, write, delete, append, append to, assign, and share.
- ■ System Customizer—Provides the users with the create, read, write, and delete permissions for the entities they create and the permission needed to customize the environment.
- ■ Common Data Service User—Allows the users to run apps in the environment and provides them with the read, create, write, and delete permissions for the records they own. All users added to the environment receive this role by default.
- ■ Delegate—Allows users to impersonate other users and run code on their behalf.
