SECURITY 18 October 2025 13 min read

Power Pages Security Architecture: Interactive Guide

Power Pages security model explained: Role-based access control, table permissions, web roles and authentication layers with interactive visualization.

Security in Power Pages is built on layers. Understanding this hierarchical model is essential for implementing secure customer portals.

This guide walks through how administrators, custom roles, authenticated users, anonymous visitors, and system components work together - from web roles and table permissions down to the site settings that expose data through the Web API. Understanding each layer is what separates a portal that merely looks secure from one that actually is.

Table of Contents

1. The Security Hierarchy

Power Pages arranges access control as five layers stacked on top of each other. Every request into the portal - a page view, a form submission, a Web API call - passes through this stack. The layers below give a quick overview; the sections that follow break down each one in detail.

Level 1: Administrator

Web role with explicit permissions - not automatic admin access!

Level 2: Custom Roles

Partner, customer, department-specific roles with table permissions

Level 3: Authenticated Users

All logged-in users (implicit "Authenticated Users" role)

Level 4: Anonymous Users

Public visitors without login - limited access

System Layer

Web API, Forms, Lists, Liquid templates - all respect permissions

2. Level 1: Administrator

Admin

Key Concept

  • Just a web role name - no special privileges
  • All data access requires explicit table permissions
  • Same rules apply as for any custom role
  • Use specific scopes (Contact/Account) over Global

What You Can Do

  • Manage portal settings and configuration
  • Assign web roles to users
  • Manage pages and content
  • Configure table permissions (if granted)

Access Types (Table Permissions)

  • Global: All records in the table
  • Contact: Records related to the user
  • Account: Records related to the user's account
  • Self: Only the user's own contact record

Best Practices

  • Avoid Global scope where possible
  • Use Contact or Account scope for most scenarios
  • Follow the principle of least privilege
  • Run regular permission audits

3. Level 2: Custom Roles

Roles

How It Works

  • Create roles for specific user groups
  • Assign table and page permissions to roles
  • Users can have multiple roles (cumulative access)
  • Configure via the Portal Management app

Common Examples

  • Partner: Access to their customers' data
  • Customer: B2B account-level access
  • Support Agent: Case management rights
  • Department Manager: Team data access

Permission Scopes

  • Account Scope: Perfect for B2B scenarios
  • Contact Scope: The user's related records
  • Parent Scope: Hierarchical relationships
  • Child Permissions: Related table access

Configuration

  • Security workspace in Design Studio (modern)
  • Or the Power Pages Management app (Dataverse)
  • Add table permissions with specific scopes
  • Assign users manually or via Power Automate

4. Level 3: Authenticated Users

Auth

Important: This Is an Implicit Role

  • Automatically assigned to ALL logged-in users
  • Cannot be removed from users
  • Only ONE per website
  • Be careful with the permissions you grant here

How It Works

  • Users are represented by Dataverse contacts
  • Can have additional custom roles
  • Permissions are cumulative across all roles
  • Managed via the Portal Management app

Typical Setup

  • Contact Scope: The user's own records
  • Self Scope: Own contact record only
  • Read Access: Reference data (products, etc.)
  • Create: Cases, leads, support requests

Authentication Methods

Local (username/password)
Microsoft Entra External ID
Azure AD B2C
Social providers (Google, LinkedIn, etc.)

5. Level 4: Anonymous Users

Public

Anonymous Users Role

  • Special role for unauthenticated visitors
  • Only ONE per website
  • Respects table permissions (but not page permissions)
  • Access to public content and forms

Site Visibility

  • Default: Internal only (Microsoft Entra auth)
  • Go-live: switch to "Public"
  • Protects partially developed sites
  • Prevents accidental data leaks

What They Can Access

  • Public pages (homepage, marketing)
  • Knowledge base articles (if configured)
  • Contact forms
  • Login and registration pages

Data Access

  • Can have table permissions (via the Anonymous role)
  • Submit data via forms
  • View filtered lists (if configured)
  • No direct Dataverse API access

6. System Layer

System

Web API, forms, lists, and Liquid templates are not a bypass around the security model - they all read the same web roles and table permissions described above.

Portals Web API

  • CRUD operations on Dataverse tables
  • Available at /_api/ endpoints
  • Must be enabled per table (site settings)
  • Requires Power Pages 9.3.3.x or later

Security Facts

  • Web API respects table permissions
  • Uses portal session authentication
  • Requires a CSRF token for all calls
  • Column permissions for field-level security

Site Settings (Required)

Enable: Webapi/<table>/enabled = true
Fields: Webapi/<table>/fields = * or list
Note: Use logical name (e.g., "account")
In Code: Use EntitySetName (e.g., "accounts")

Other Components

  • Forms & Lists: Respect table permissions
  • Liquid Templates: Access to the {{ user }} object
  • JavaScript: Client-side code execution
  • FetchXML: Query Dataverse data

Limitations

  • Not for third-party integration
  • Configuration tables not supported
  • Actions and functions not available
  • Server-side caching for performance

7. Key Security Concepts

Web Roles

Define user groups (Partner, Customer, Admin)

  • Assigned to Contact records
  • Can have multiple roles per user
  • Permissions are cumulative

Table Permissions

Control data access per role

  • Global, Contact, Account, Self scopes
  • Create, Read, Write, Delete access
  • Column-level security available

Critical: Administrator Role Misconception

The "Administrator" web role is just a name - it has no special privileges. All data access requires explicit table permissions, just like any custom role. Always use specific scopes (Contact/Account) over Global scope whenever possible.

Key Takeaways

Essential Security Principles

  • Administrator is just a name: No automatic privileges - all access requires explicit table permissions
  • Multiple roles, cumulative permissions: Users can have multiple roles, permissions add up
  • Authenticated Users role is automatic: Cannot be removed, assigned to ALL logged-in users
  • Prefer specific scopes: Use Contact or Account scope over Global whenever possible
  • System components respect permissions: Web API, Forms, and Lists all honor table permissions

8. Security Best Practices

Do's

  • Use Contact or Account scope for B2B scenarios
  • Apply the principle of least privilege
  • Enable column permissions for field-level security
  • Configure MFA for sensitive areas
  • Run regular security audits of role assignments
  • Enable Dataverse auditing for compliance

Don'ts

  • Don't use Global scope unless absolutely necessary
  • Don't grant broad permissions to the Authenticated Users role
  • Don't implement security logic only client-side in JavaScript
  • Don't enable the Web API without proper table permissions
  • Don't mix authentication providers without a clear strategy

9. Implementation Guide

Here's a practical step-by-step approach to implementing secure Power Pages portals:

Setup Checklist

  1. Plan your roles:

    Map business roles (Partner, Customer, Internal) to web roles

  2. Define table permissions:

    Determine which tables each role needs to access and with what scope

  3. Configure authentication:

    Set up Entra ID (internal) and Entra External ID (external) providers

  4. Implement row-level security:

    Use Contact or Account scope to ensure users see only their data

  5. Enable field-level security:

    Configure column permissions for sensitive fields

  6. Test thoroughly:

    Verify permissions with test users in each role

  7. Enable auditing:

    Turn on Dataverse auditing for compliance tracking

10. Frequently Asked Questions

What is the difference between Web Roles and Table Permissions in Power Pages?

Web Roles define user groups (like "Partner", "Customer", "Administrator") while Table Permissions control what data each role can access in Dataverse tables. A user can have multiple roles, and permissions are cumulative across all assigned roles.

Does the Administrator web role have automatic access to all data?

No. The "Administrator" web role is just a name - it has no special privileges. All data access requires explicit table permissions, just like any custom role. You should use specific scopes (Contact/Account) over Global scope whenever possible.

What authentication methods does Power Pages support?

Power Pages supports Microsoft Entra ID (for internal users), Microsoft Entra External ID (for external customers and partners), SAML 2.0, OpenID Connect, and local authentication (username/password). Multi-factor authentication (MFA) can be enforced for sensitive areas.

How does the Portals Web API respect security permissions?

The Portals Web API fully respects table permissions and uses portal session authentication. It requires CSRF tokens for all calls and supports column permissions for field-level security. The API must be explicitly enabled per table via site settings.

11. Conclusion

Power Pages security architecture provides enterprise-grade access control without requiring deep security expertise. By understanding the hierarchical model - administrators, custom roles, authenticated users, anonymous visitors, and the system layer that enforces it all - and by following the best practices above, you can build secure customer portals that protect sensitive data while providing excellent user experiences.

Need Security Architecture Review?

Get expert guidance on implementing secure access control for your Power Pages portal.

Book Consultation
Tino Rabe

Tino Rabe

Power Pages Spezialist · Former Microsoft MVP

Power Pages specialist, former Microsoft MVP. I help companies build secure customer portals: architecture workshop, weekly coaching, security audits.

When was your portal last independently reviewed?

Fixed-fee security audit, or just talk it through first.

Book a call