Power Pages Security
External websites need serious security. Learn how Power Pages handles authentication, table permissions, web roles, and page access rules to keep your data safe.
Why does external security matter more?
Imagine the difference between letting someone into your office vs letting a stranger into your house.
Internal apps (Power Apps, model-driven apps) are like your office — only employees with ID badges get in. You trust them somewhat because they already passed background checks.
Power Pages is like opening your front door to the public. Anyone on the internet can visit. You need locks, cameras, and rules about which rooms visitors can enter.
Tom’s property portal is public. Without security, a random visitor could see every buyer’s personal details, delete listings, or submit fake bookings. Security in Power Pages is not optional — it is essential.
The four layers of Power Pages security
Think of security as four locks on the door, each controlling something different:
| Layer | Question It Answers | Example |
|---|---|---|
| Authentication | Who are you? | Tom’s buyer logs in with email and password |
| Web roles | What group are you in? | ”Buyer” role vs “Agent” role |
| Table permissions | What data can you see or edit? | Buyers see only their own saved properties |
| Page access rules | Which pages can you visit? | Only logged-in buyers see the “My Bookings” page |
Authentication: proving who you are
Power Pages supports multiple ways for external users to prove their identity.
| Authentication Method | How It Works | When to Use |
|---|---|---|
| Local authentication | Email and password stored by the site | Simple portals, quick setup |
| Azure AD B2C | Microsoft’s identity service for external users | Enterprise portals needing MFA and advanced policies |
| Social providers | Sign in with Google, Facebook, LinkedIn, Microsoft account | Consumer-facing sites where convenience matters |
| SAML / OpenID Connect | Federate with an external identity provider | Partner portals where partners use their own login system |
Tom chose local authentication for simplicity — buyers register with an email and password. Later, he plans to add Azure AD B2C for multi-factor authentication.
Anonymous vs authenticated access
Not every page requires login. Power Pages supports anonymous access for public-facing pages like the homepage or listings page. Tom’s property listings page is visible to everyone. But the “My Bookings” page? That requires authentication.
You control this per page using page access rules.
Web roles: grouping users
Once a user is authenticated, you assign them a web role. Think of web roles as labels that say “this person is a buyer” or “this person is an agent.”
Web roles are similar to security groups in Entra ID, but they are designed specifically for external Power Pages users.
| Tom’s Web Roles | Who Gets It | What They Can Do |
|---|---|---|
| Anonymous Users | Anyone (not logged in) | Browse listings, view public pages |
| Buyer | Registered buyers | Save favourites, book viewings, see their own data |
| Agent | Summit Realty staff on the portal | View all bookings, manage listings |
A user can have multiple web roles, and their permissions add up (they are cumulative).
Table permissions: controlling data access
This is the most important security layer. Table permissions define which Dataverse rows a user can read, create, update, or delete.
There are four permission scopes:
| Scope | What It Means | Example |
|---|---|---|
| Global | Access all rows in the table | Agents see every property listing |
| Contact | Access only rows linked to the logged-in user’s contact record | Buyers see only their own bookings |
| Account | Access rows linked to the user’s parent account (company) | A partner company sees all their employees’ submissions |
| Parent | Access rows linked through a parent table relationship | Viewing enquiries that belong to a specific property |
Tom's table permissions in action
Tom set up these permissions:
- Property Listings table: Buyers get Global Read (browse all listings). Agents get Global Read, Create, Update (manage listings).
- Viewing Requests table: Buyers get Contact Create and Read (submit and see only their own requests). Agents get Global Read and Update (see and respond to all requests).
This means a buyer named Sarah can submit a viewing request and see her own requests, but she cannot see requests from other buyers. An agent can see everything.
Exam tip: table permission scopes
The exam loves scenarios where you pick the correct scope:
- “Users should see ALL records” → Global
- “Users should see only THEIR records” → Contact
- “Users should see their COMPANY’s records” → Account
- “Users should see records through a related parent” → Parent
Page access rules: controlling navigation
Page access rules determine which pages a user can visit. You link a page to a web role.
If a user does not have the required web role, the page does not appear in the navigation and returns a 403 error if accessed directly.
Tom restricted the “Agent Dashboard” page to the Agent web role. Buyers never see it in the menu, and typing the URL directly shows an access-denied message.
Internal vs external security compared
| Feature | Authentication | Roles | Data access control | Page visibility |
|---|---|---|---|---|
| Internal (Dataverse) | Microsoft Entra ID (automatic) | Dataverse security roles | Row-level security, column security, business units | App-level access via security roles |
| External (Power Pages) | Local, Azure AD B2C, social, SAML | Web roles (portal-specific) | Table permissions with Global/Contact/Account/Parent scopes | Page access rules linked to web roles |
The key takeaway: Power Pages does not use Dataverse security roles for external users. It has its own parallel system — web roles and table permissions — designed specifically for people outside your organisation.
Exam tip: security roles vs web roles
This is a common trick question:
- Dataverse security roles control access for internal users (inside Power Apps, model-driven apps)
- Web roles + table permissions control access for external users (on Power Pages sites)
If the question says “external user” or “portal visitor” — the answer involves web roles and table permissions, never Dataverse security roles.
Flashcards
Knowledge check
Tom wants buyers on his Power Pages site to see only their own viewing requests, not other buyers' requests. Which table permission scope should he use?
Aisha's partner portal at Coastal Logistics lets shipping partners log in using their own company's identity provider. Which authentication method supports this?
A Power Pages site has an 'Admin Dashboard' page that should only be visible to users with the 'Agent' web role. What controls this?
Next up: Design Studio and Building — get hands-on with the tool you use to build and edit Power Pages sites.