FusionOps Security for Professional Developers¶

Microsoft Power Platform offers a spectrum of extensibility points and tooling capabilities. This guidance provides professional developers an overview of roles, paradigms, and security best practices for using Power Platform.

Authentication¶

Power Platform uses Azure Active Directory (Azure AD) to identify users. Conditional Access policies can be used to fine-tune user access based on contextual factors such as user type, device, location, and app, then decide whether to allow, deny, or restrict user access. The table below provides a high-level overview of different supported authentication protocols supported by Power Platform products.

App type	Model-driven Apps	Canvas Apps	Power Pages	Power Virtual Agents
Intended Use Cases	Well suited to data-dense business process-driven apps, making it easy for users to move between related records and manage complex processes (e.g., employee onboarding, member relationships, or sales processes). A Model-driven app can be delivered both as a cross-browser web app and a cross-platform mobile app on iOS, Android and Windows.	Ideal for surfacing simple business data for task-based applications (e.g., event registration or approval workflows). Canvas app design is done by dragging and dropping elements onto a canvas, much like a PowerPoint slide. Canvas apps integrate business data from a wide variety of Microsoft and third-party sources through connectors. In addition to being run on a browser or mobile device, apps can be embedded in SharePoint, Power BI, or Teams.	Power Pages is a low-code SaaS platform for creating, hosting, and administering modern external-facing websites. It enables both citizen and professional devs to rapidly design, configure, and publish websites that work across web browsers and devices, enabled by built-in capabilities like Liquid templates Responsive Design, and Progressive Web Apps (PWA). Power Pages can serve up both authenticated and unauthenticated experiences.	AI-powered chatbots as a Low-code SaaS platform, and covers a range of use cases, including both providing simple answers to common questions and resolving issues requiring complex conversations. Engage with customers and employees in multiple languages across websites, mobile apps, Facebook, Microsoft Teams, or any channel supported by the Azure Bot Framework.
Target audience	Internal users, e.g., Employees, Contractors, Business Partners with known identities.	Internal users, e.g., Employees, Contractors, Business Partners with known identities.	External Users / End customers e.g., Members of the Public, Rate Payers of a city council, Frequent Flyers of an airline, Alumni of an education institution.	Both internal and external users.
Authentication Providers & Protocols	Azure AD	Azure AD, AAD B2B Guest	Azure AD (OpenID Connect, SAML 2.0, WS-Federation) Azure AD B2C (OpenID Connect) Active Directory Federation Services (SAML 2.0, WS-Federation) Microsoft, LinkedIn, Facebook, Google (OAuth 2.0)	Azure AD, OAuth2
Customer success story	Blackmore	Ecolab	City of Columbus	T-Mobile
Docs reference	Model-driven apps docs	Canvas Apps docs	Power Pages docs	PVA docs

Recommended links:

• Authenticating to Power Platform services
• What is Conditional Access?
• Set up Azure AD Conditional Access

Environments¶

Environments are containers that administrators can use to manage apps, automation, connections, and other assets. Environments also govern permissions allowing organization users to use the resources.

A single default environment is automatically created by Power Apps for each tenant and shared by all users in that tenant. However, to follow application lifecycle management (ALM) principles, you should have separate environments for app development, testing, and production.

Each environment is created under an Azure Active Directory (Azure AD) tenant, and only users within that tenant can access its resources.

To enable data privacy and data sovereignty, an environment is bound to a geographic location (e.g., Australia, or New Zealand). When you create an app in an environment, that app is routed only to the data centers in that geography.

Access is controlled at three levels in an environment: Environment roles, Resource permissions for Power Apps, Power Automate, etc., and Dataverse security roles (if a Dataverse database is provisioned). When Dataverse is created in an environment, the Dataverse roles will take over for controlling security in the environment, and all environment admins and makers are migrated.

Recommended links:

• Environments overview
• Establishing an environment strategy

Environment security roles¶

Environments have two built-in roles that provide access to permissions within an environment:

Role	Description
Environment admin	perform all administrative actions on an environment
Environment maker	create new resources within an environment, including apps, connections, custom connectors, gateways, and flows using Power Automate

Note: Ensure that developer accounts are provisioned as an `Environment Maker.' Review relevant IT policies to understand the established environment strategy in the subject tenant with the responsible IT administrators.

Recommended links:

• Configure user security to resources in an environment

Guest users¶

Power Apps can be shared with guest users of an Azure AD tenant. You can invite external business partners, contractors, and third parties to work in your company's apps.

Prerequisites:

• Enable B2B external collaboration for the tenant in Azure AD.
• You must be an Admin or have the Guest Inviter role to add guests to a tenant.
• If an app doesn't connect to Dataverse, the guest user must have a license with Power Apps use rights that match the capability of the app assigned through the tenant hosting the app being shared or the home tenant of the guest user.
• If an app connects to Dataverse, the guest user must have a license with Power Apps use rights that match the capability of the app, and it must be assigned in the tenant hosting the app.

Considerations and Limitations for Guest Access¶

• Guests can be assigned the User role or Co-owner role for apps shared with them. However, guests cannot edit apps (Power Apps support for B2B guest maker is in preview now).
• Power Apps guest access uses Azure B2B.
• Power Apps Mobile doesn't support authentication using Azure AD direct federation.
• Power Apps per app plans are scoped to apps in a specific environment, so they can't be recognized across tenants.
• Power Apps included with Office and Power Apps per user plans have the following characteristics:
  • In the Azure public cloud, they are recognized across tenants in guest scenarios because they aren't bound to a specific environment.
  • In Azure national or sovereign clouds, they are recognized across tenants in guest scenarios.
  • Licenses are not recognized across tenants in different Azure clouds.

Data Loss Prevention Policies¶

Within an environment, an administrator can configure the Data Loss Prevention (DLP) policies to enforce rules around which connectors can be used together by classifying connectors as either Business or Non-Business. A connector in the Business group can only be used with other connectors from that group in any given app or flow. To block the usage of specific connectors altogether, classify them as Blocked.

Administrators can also use:

• Connector Action Control to allow/block specific connector actions for each connector.
• Connector Endpoint Filtering to secure connection endpoints by configuring an ordered list of endpoint patterns to allow/block.

Recommended links:

• Data loss prevention policies
• Data Loss Prevention policies for enhanced Power Platform governance

Security for Power Platform Products¶

Canvas Apps¶

Canvas apps allow you to build a business app from a canvas without writing code. Users can design the app by dragging and dropping elements onto a canvas, just as you would create a slide in PowerPoint.

Building a Canvas App¶

To create a canvas app, you must be at least an Environment Maker.

Saving and Publishing a Canvas App¶

Whenever you save changes to a canvas app, you automatically publish them only for yourself and anyone else who has permission to edit the app. When you finish making changes, you must explicitly publish them to make them available to everyone with whom the app is shared.

Sharing a Canvas App¶

After you build a canvas app, specify which users in your organization can run the app and who can modify and even re-share it.

To share your canvas app, you must specify each user by name or a security group in Azure AD. If everyone would benefit from your app, specify that your entire organization can run it.

If you want to allow users to edit and share your app but not delete or change owner, you can grant them Co-owner permission.

Note: Regardless of permissions, only one person can edit an app at a time. If one person opens the app for editing, others can run it but not edit it.

Recommended links:

• What are canvas apps?
• Share a canvas app with your organization

Model-Driven Apps¶

Model-driven apps are built on Dataverse, and can only connect to a Dataverse environment. All the data that defines a model-driven app is stored within Dataverse.

Access to tables is defined using security roles, and these roles govern the actions that users can perform with the tables within Dataverse. Without this, users will have no meaningful access to the app.

System Administrator role can perform all administrative actions on an environment including:

• Adding or removing a user or group from either the Environment Admin or Environment Maker role.
• Provisioning a Microsoft Dataverse database for the environment.
• Viewing and managing all resources that are created within an environment.
• Setting data loss prevention policies.

Environment maker role can create new resources within an environment like apps, connections, custom connectors, and gateways. The following applies to members of the Environment Maker role:

• Environment Makers can distribute the apps they build in an environment to other users within an organization by sharing the app with individual users, security groups, or all users in the organization.
• Users or groups assigned to these environment roles are not automatically given access to the environment's database (if it exists). They must be given access separately by a Database owner.
• When adding a user to an environment, they are assigned two roles by default:
  • Dataverse User (this role is created when you instantiate an instance of a Dataverse database, and all users in the environment are assigned this role)
  • Environment Maker

Building a model-driven app¶

To build a model-driven app that extends Dataverse, you must be at least an Environment Maker and a System Customizer.

We recommend creating your model-driven app from a solution. A solution is a package that can contain Dataverse tables, forms, views, apps, flows, and other components. Consider including a security role for users in the solution as well.

Saving and publishing a model-driven app¶

Model-driven apps cannot be published without all the required components. Some components rely on others, and this relationship is known as a dependency.

The process of checking for dependencies within a model-driven app is known as validation. When an app is validated, the app designer canvas shows details about missing assets.

After adding components, validating, and saving the app, you can publish.

Sharing a model-driven app¶

Model-driven apps use role-based security for sharing. The security role contains privileges that define a set of actions that can be performed on tables within the app.

All app users must be assigned one or more predefined or custom security roles. Conversely, security roles can be assigned to teams.

The process for sharing a model-driven app depends on how the Microsoft Dataverse data table privileges are assigned for the tables in the app.

The app sharer must have admin privileges to the specific environment (or be a Power Platform administrator). The app sharer must have a security role with equal or greater privileges than the security role they assign to the app and to other users. Usually, this takes the form of the app sharer having the Dataverse System Administrator or System Customizer security role.

Recommended links:

• What are model-driven apps in Power Apps?
• Share a model-driven app using Power Apps

Power Automate¶

Power Automate is a powerful tool that allows you to:

• Automate business processes
• Send automatic reminders for past-due tasks
• Move business data between systems on a schedule
• Connect to more than 500 data sources or any publicly available API
• Automate tasks on your local computer, like computing data in Excel.

Power Automate can be used with or without Microsoft Dataverse.

Building a flow¶

To build a flow, you need to be at least an Environment Maker- if this flow is using Microsoft Dataverse, you must also be aBasic User.

Sharing a flow¶

There are three primary ways to share a cloud flow in Power Automate:

• Add an owner to a cloud flow. Adding an owner to a cloud flow is the most common way to share a cloud flow. Any owner of a cloud flow can perform these actions:
  • View the run history.
  • Manage the properties of the flow (for example, start or stop the flow, add owners, or update credentials for a connection).
  • Edit the definition of the flow (for example, add or remove an action or condition).
  • Add or remove other owners (but not the flow creator).
  • Delete the flow.
• Share a cloud flow with run-only privileges. Instant flows (flows that use a manual trigger, such as a button or an item being selected) can be shared by using run-only permissions. Any user who is added as a run-only user won't have access to edit or modify the flow in any way; they'll only have permission to trigger the flow.
• Share a copy of a cloud flow. You can share a copy of a cloud flow with another user, who can then use the definition of the flow as a template. This provides a mechanism for sharing the general structure of a cloud flow without sharing any connections, while allowing the recipient to modify their flow independently to fit their specific needs. Note: sharing a copy creates an independent flow instance for the recipient, and you can't revoke access to the flow after you share it.

Note: You must be the creator or owner to add or remove owners from a cloud flow. An owner, co-owner, or admin can change the owner of a solution-aware flow to another user to ensure business continuity. After the change of ownership completes, both the original owner and the new owner become co-owners of the flow. You can change the owner to an individual (not a distribution list) or a user account used as a service account.

Recommended links:

• Get started with Power Automate
• Share a cloud flow

Power Virtual Agents¶

Power Virtual Agents lets you create powerful AI-powered chatbots that can be created with a guided, no-code graphical interface - and without the need for data scientists or developers.

Building a bot¶

To build a bot, you need to be at least an Environment Maker and have the security role of bot author assigned to you.

Sharing a bot¶

Everyone you share the bot with can view, edit, configure, share, and publish the bot, but can't delete it

Bot owners and managers always have permission to chat with a bot. You can share bots with other users or security groups so their members can only chat with the bot.

Note: The bot's end user authentication setting must be configured to Only for Teams or Manual, with Azure AD or Azure AD V2 as the provider. Required user sign-in must be enabled to manage who can chat with the bot in your organization.

Recommended links:

• Power Virtual Agents overview
• Share a bot

Power Pages¶

Microsoft Power Pages is a secure, enterprise-grade, low-code software as-a-service (SaaS) platform for creating, hosting, and administering modern external-facing business websites. It provides both an unauthenticated experience (think traditional Content Management System (CMS)) and authenticated experience, which serves relevant content to the logged-in user (think online banking experience).

From an identity and authentication perspective, Power Pages differs from Canvas App, Model-driven App, in that it caters to external identity providers and, therefore, more authentication protocols. When building websites with Power Pages, it is imperative to understand if the intended providers and protocols are in the supported list, linked provided below.

For authorization access, Web roles is a robust role-based access control (RBAC) implementation that controls granular access to page permissions (think web page content) and table permissions (think Dataverse tables). Each authenticated user is associated with a contact record in Dataverse and can be assigned with multiple Web roles.

Web App Firewall technology (WAF) is commonly used in front of Power Pages to protect high-profile use cases where a Power Pages implementation can be a target for bad actors in a cybersecurity context. Power Pages can be integrated with any web application firewall infrastructure to provide extra protection against common attacks. Refer to link below on setting up Azure Front Door.

To mitigate potential risks introduced by Cross-Site Scripting (XSS) attacks and more recently Clickjacking, modern browsers implement the new Content-Security-Policy HTTP header, which helps reduce the attack surface by declaring which dynamic resources are allowed to load. Power Pages also support this through Content Security Policy (CSP). The link below provides a step-by-step walk-through on how to enable this.

Note: As a pro dev, the minimum security privileges required to build web apps with Power Pages are Portal owner and System Customizer.

Power Pages can be used with or without Microsoft Dataverse.

Power Pages has a robust security model to protect business information properly.

Power Pages can be integrated with any web application firewall infrastructure to provide extra protection against common web application attacks.

Authenticated users¶

Users can be provided access to a site through authentication. Microsoft Dataverse contact records represent Power Pages users. Power Pages can be integrated with many authentication providers, such as Azure AD B2C, Microsoft, and LinkedIn.

Authenticated users can then be assigned to web roles that will provide specific access to information on the site.

Web roles¶

Web roles can be created to allow users to perform any special actions or access any protected content and data on the site. Web roles link to users, table permissions, and page permissions. Because contacts can be assigned multiple web roles, they can be provided cumulative access to site resources.

All authenticated users (contacts) are automatically assigned the Authenticated Users web role.

A site can be visited by anonymous users (unauthenticated) and given access to assets through the Anonymous Users web role.

Recommended link:

• Create web roles for portals

Table permissions¶

Accessing Dataverse information through lists, forms, Liquid, and the Web API is the default, and is protected by table permissions. You can configure table permissions to allow different levels of access and privileges to Dataverse records, and table permissions are associated to web roles to provide appropriate access to users.

Recommended link:

• Configure security using table permissions

Web API site settings¶

Power Pages allow accessing Dataverse data through Web API operations. In addition to table permissions, column permissions and Web roles, the tables and columns required to interact with the portal Web API must be declared in the Site Settings section.

Recommended links:

• Portals Web API overview
• Configure site settings for portals

Column permissions¶

In addition to Table permissions and Web API site settings, individual table columns can be optionally associated with Web roles to allow users to limit the scope (create, read, or update) of table permission access.

Recommended link:

• Column permissions

Page permissions¶

Individual pages containing content or other components can also be protected by configuring page permissions that are associated with web roles to allow access.

Recommended links:

• Overview of authentication in Power Pages
• Power Pages security Overview
• Set up Azure Front Door with Power Pages
• Manage Content Security Policy
• Power Pages administration roles

Dataverse security¶

Microsoft Dataverse provides a security model that protects data integrity and privacy, and supports efficient data access and collaboration.

The following is a high-level overview of how the security model is implemented in Dataverse.

• Users are authenticated by Azure Active Directory (Azure AD).
• Licensing is the first control gate to allowing access to Power Apps components.
• Ability to create applications and flows is controlled by security roles in the context of environments.
• A user's ability to see and use apps is controlled by sharing the application with the user. Sharing of canvas apps is done directly with a user or Azure AD group but is still subject to Dataverse security roles. Sharing of model-driven apps is done via Dataverse security roles.
• Environments act as security boundaries enabling different security needs in each environment.
• Flows and Canvas apps use connectors; the specific connections credentials and associated service entitlements determine permissions when apps use the connectors.
• Environments with Dataverse add support for more advanced security models that are specific to controlling access to data and services in the environment with a Dataverse database.

Note: The data operations in your code run in the context of a user. An exception will be thrown if your code attempts to perform an operation that the user is not allowed to perform. Code will only be able to perform operations based on the privileges assigned to the user account through security roles or team membership. That is why you should understand how to configure and manage security roles

Recommended links:

• Security concepts in Microsoft Dataverse

Role-based security¶

Dataverse uses role-based security to group together a collection of privileges. These security roles can be associated directly to users or to Dataverse teams and business units. Users can then be associated with the team, and all users associated with the team will benefit. A key concept of Dataverse security to understand is all privilege grants are accumulative, with the greatest amount of access prevailing. If you gave broad organization-level read access to all contact records, you can’t go back and hide a single record.

graph BT;
    A[User]-->B[Team]-->C[Business unit];

Teams¶

Using Microsoft Dataverse Teams is optional. However, teams provide an easy way to share business objects and let you collaborate with other people across business units. Although a team belongs to one business unit, it can include users from different business units, and you can associate a user with more than one team.

Types of teams

• Owning team can own records, which give any team member direct access to that record.
• Access teams provide a more advanced concept of sharing. Access Teams provides auto-creation of a team and sharing of record access with the team based on an Access Team Template or with manual add/remove of its members. Access teams are more performant because they don’t allow owning records by the team or having security roles assigned to the team.
• Azure AD group team is similar to owner teams. An Azure AD group team can own records and can have security roles assigned to the team. Security and Office are two group team types that correspond directly to Azure AD group types. Team members are dynamically derived (added and removed) when they access an environment based on their Azure AD group membership.

Security roles¶

A security role defines how different users, such as salespeople, access different types of records. To control access to data, you can modify existing security roles, create new security roles, or change which security roles are assigned to each user. Each user can have multiple security roles.

Environments include predefined security roles that reflect common user tasks with access levels defined to match the security best-practice goal of providing access to the minimum amount of business data required to use the app.

Security role	Database privileges*	Description
Environment Admin	Create, Read, Write, Delete, Customizations, Security Roles	Can perform all administrative actions on an environment
Environment Maker	Customizations	Can create new resources associated with an environment, including apps, connections, custom APIs, gateways, and flows using Microsoft Power Automate. However, this role has no privileges to access data within an environment. More information: Environments overview
System Administrator	Create, Read, Write, Delete, Customizations, Security Roles	Has full permission to customize or administer the environment, including creating, modifying, and assigning security roles. Can view all data in the environment. More information: Privileges required for customization
System Customizer	Create (self), Read (self), Write (self), Delete (self), Customizations	Has full permission to customize the environment. However, users with this role can only view records for environment entities that they create. More information: Privileges required for customization
Basic User	Read (self), Create (self), Write (self), Delete (self)	Can run an app within the environment and perform common tasks for the records that they own. This only applies to non-custom entities.
Delegate	Act on behalf of another user	Allows code to impersonate or run as another user. Typically used with another security role to allow access to records. More information: Impersonate another user
Support User	Read Customizations, Read Business Management settings	Has full Read permission to customization and business management settings to allow Support staff to troubleshoot environment configuration issues. Does not have access to core records.

* The scope of these privileges is global unless specified otherwise.

Note: - Environment Maker and Environment Admin are the only predefined roles for environments with no Dataverse database. - The Environment Maker role can create resources within an environment and distribute the apps they build in an environment to other users in your organization. They can share the app with individual users, security groups, or all users in the organization. - For users who make apps that connect to the database and need to create or update entities and security roles, you need to assign the System Customizer role in addition to the Environment Maker role. This is necessary because the Environment Maker role doesn't have environment data privileges. - If the environment has a Dataverse database, a user must be assigned the System Administrator role instead of the Environment Admin role for full admin privileges, as described in the preceding table.

The following table describes which resources can be authored by each security role.

Resource	Environment Maker	Environment Admin	System Customizer	System Admin
AI Builder	-	-	Yes	Yes
Canvas app	Yes	Yes	Yes	Yes
Cloud flow	Yes (non-solution aware)	Yes	Yes (solution aware)	Yes
Connector	Yes	Yes	-	Yes
Connection	Yes	Yes	-	Yes
Data gateway	Yes	Yes	-	Yes
Dataflow	Yes	Yes	-	Yes
Dataverse tables	-	-	Yes	Yes
*Desktop flow	-	-	Yes	Yes
Model-driven app	Yes	-	Yes	Yes
Solution framework	Yes	-	Yes	Yes
Website (Power Pages)	-	-	Yes	Yes

Recommended links:

• Security roles and privileges

Column-level security¶

Column-level permissions are granted at the table level, but you may have specific columns associated with a table that contain data that is more sensitive than the other columns. Column-level security controls access to specific columns in these situations.

The scope of column-level security is organization-wide and applies to all data access requests, including the following:

• Data access requests from within a client application, such as a web browser, mobile client, or Microsoft Dynamics 365 for Outlook.
• Web service calls using the Microsoft Dataverse web services (for use in plug-ins, custom workflow activities, and custom code)
• Reporting (using Filtered Views)

Hierarchy security¶

The hierarchy security model extends Dataverse security by allowing managers to access their direct reports' records or work on their behalf. It can be used with all other existing security models.

Two security models can be used for hierarchies:

• The Manager hierarchy is based on the management chain or direct reporting structure, where the manager’s and the direct report’s relationship is established by using the Manager field on the user table. A manager must be within the same business unit as the direct report, or in the parent business unit of the direct report’s business unit, to access the direct report’s data.
• The Position hierarchy is based on various job positions in the organization that can be defined and arranged in the hierarchy using the Position table. This model allows data access across business units.