Think Your Power Pages Are Secure? Check These 5 Layers First

 Power Pages Security ensures that data and content exposed through a Power Pages (formerly Power Apps Portals) website are protected and only accessible to the right users. Technically, it relies on Dataverse security, web roles, page permissions, and table permissions to control how internal and external users interact with data. Below is a deep technical breakdown:

1. Site Visibility

 Purpose: Controls who can see the website.

Options:

• Public – Anyone can access the site without login.
• Private (Authenticated Users Only) – Only users with valid credentials (Azure AD, local portal account, B2C, etc.) can access the site.

 Technical Note: Site visibility doesn’t restrict data access; it only controls entry to the portal.

Purpose: Identifies who the logged-in user is to apply security.

Supported Authentication Providers:

• Azure AD (Office 365 users)
• Azure AD B2C (External Users)
• Local authentication (Username & Password)
• External identity providers (Google, LinkedIn, etc.)

Technical Role: Authenticated users are mapped to Contacts in Dataverse, which are linked to Web Roles to enforce security.

3. Web Roles

Purpose: Similar to security roles in Dataverse, but specific to Power Pages.

Function:

• Assign table permissions.
• Assign page permissions.
• Determine which parts of the site a user can access.

 Key Points:

• A single user (contact) can have multiple web roles.
• Security logic flows from Web Role → Permissions → Dataverse Data.

4. Page Permissions

Purpose: Controls who can access a specific page or set of pages.

 Options:

1.  Anonymous Access – Anyone can access.
2.  Authenticated Users Only – Only logged-in users can access.
3.  Web Roles Specific – Restricts access to users with specific web roles.

 Technical Impact:

If page permissions deny access, data-level permissions don’t apply because the page is not reachable.

5. Table Permissions

Purpose: Enforces row-level and column-level security on Dataverse tables exposed through Power Pages.

Components:

• Scope: Determines which records are accessible.
• Global, Contact, Account, Self, Parent, etc.
• Access Rights: CRUD (Create, Read, Update, Delete).
• Web Role Link: Table permissions are linked to web roles to decide which logged-in users get access to data.

Technical Example:

Table Permission for Case Table

•     Scope = Contact
•      Read access = Yes
•      Linked to Customer Web Role
•      Effect: Users only see cases related to their contact record.

 How They Work Together

1. Site Visibility: Controls entry to the portal.
2. Authenticated Users: Identifies logged-in users.
3. Web Roles: Assigns security permissions to those users.
4. Page Permissions: Controls page-level access.
5. Table Permissions: Controls data-level access in Dataverse.

Security Flow Example:

Power Pages Security ensures that only the right users can access the right content and data within a Power Pages site. It combines Site Visibility, Authenticated Users, Page Permissions, Table Permissions, and Web Roles to provide a layered security model. Site Visibility controls who can see the site (public vs. private), while Authenticated Users verify identity for restricted content. Page Permissions determine which pages a user can view or edit, and Table Permissions define access to Dataverse data at the record and column level. Web Roles act as the glue, linking users to the permissions they need. Together, these components create a robust, end-to-end security framework that protects both the site and underlying data.