Power Pages: Security and Roles
Understand and configure security in Power Pages: contacts, web roles, table permissions, and web page access control rules.
Introduction to Power Pages Security
Power Pages is the Power Platform component that enables building external-facing portals based on Microsoft Dataverse, accessible by both authenticated and anonymous users. Security in Power Pages is based on an authentication and authorization model that controls which content and data each user can access. Understanding how to configure web roles, table permissions, and page access rules is essential to ensure data protection and a consistent experience for end users.
The Power Pages security mechanism relies on a set of dedicated Dataverse tables that define access privileges for both content and data. Each authenticated portal user is represented by a record in the Contact table, while authorizations are managed through the Web Role, Table Permission, and Web Page Access Control Rule (WPACR) tables.
Authentication and Authorization Architecture
According to the architecture outlined in the Microsoft Power Platform Enterprise Architecture model, the Power Pages security structure includes the following elements:
- Contact: Represents the portal user. Each contact can have one or more assigned web roles.
- Web Role: The main container for privilege-based settings. Each web role can be linked to multiple web page access control rules and table permissions.
- Web Page Access Control Rules (WPACR): Define permissions for individual pages within the portal, allowing or denying read or edit access.
- Table Permission: Specifies data-level permissions within Dataverse, defining the scope (records related to the contact, the parent account, or global) and privileges (read, write, create, delete, append, append to).
This diagram highlights the logical flow of security: every user (contact) is associated with one or more web roles, which in turn determine the permissions for pages and data. The result is a granular, manageable security model consistent with corporate policies.
Configuring Security in Power Pages
Security configuration in Power Pages is mainly done through the administration portal and Power Pages Studio. Power Pages Studio allows administrators to define authentication providers, configure accessible Dataverse tables, and set visibility rules for site pages.
Authentication and User Types
Power Pages supports both anonymous and authenticated users. Anonymous users can view public content, while authenticated users must be registered as contacts in Dataverse. Authentication options include Azure AD B2C, external providers, or local authentication.
Administrators can also apply IP-based restrictions to limit portal access to specific geographic areas, further strengthening security.
Data-Level Permissions (Table Permission)
Table Permissions define the level of access to Dataverse data. You can configure permissions for:
- Records related to the authenticated contact.
- Records related to the contact's parent account.
- All records (global scope).
Available privileges include read, write, create, delete, append, and append to. This allows precise control over which data each user can view or modify.
Page Access Rules (WPACR)
Web Page Access Control Rules manage permissions at the page level. You can grant read-only or edit access. Without an access rule, a page will not be visible to the portal user, even if it exists physically on the site.
Web Roles
Web Roles are the core of the authorization system. Each role can be associated with multiple Table Permissions and WPACRs. For instance, a "Customer Manager" role may have full access to customer records and update forms, while a "Customer Viewer" role might have read-only access to public pages and selected data.
Security Best Practices
To ensure a secure and scalable Power Pages implementation, Microsoft recommends following these best practices:
- Avoid granting unnecessary global privileges.
- Create specific roles for user categories (managers, partners, customers).
- Use the “least privilege” principle to limit access rights to what is strictly necessary.
- Regularly review and update Table Permissions and WPACRs.
- Integrate authentication with Azure AD B2C for centralized identity management.
Additionally, to extend portal security and functionality, you can use the Portals Web API to securely interact with Dataverse or the Liquid Template Language to control content visibility directly in the front-end.
Integration with Dataverse and Azure
Power Pages operates on a shared Microsoft Azure infrastructure, but all configuration is stored in Dataverse. This ensures consistency, traceability, and ease of administration. The combined use of Azure Active Directory and Dataverse provides unified identity and authorization management, aligned with corporate security standards.
Summary Schema
Power Pages Roles and Permissions
- Contact – Authenticated user, represented in Dataverse.
- Web Role – Container for security policies.
- Web Page Access Control Rule – Manages page visibility and permissions.
- Table Permission – Defines access privileges to Dataverse data.
Frequently Asked Questions
How are users managed in Power Pages portals?
Authenticated users are represented as records in the Contact table. Each contact can belong to one or more web roles, which determine access privileges for pages and data.
What is the difference between a Web Role and a Table Permission?
The Web Role defines the security group and its policies, while Table Permission defines the detailed data-level permissions in Dataverse, such as access type and record scope.
Can access be restricted by geographic area?
Yes, Power Pages allows configuring IP-based restrictions, limiting portal access to specific regions.
Want to learn more about Power Platform Security?
Discover how to securely configure Power Pages, Dataverse, and other platform components. Check the official Microsoft documentation or explore our training courses.
 
          