8.3 External Identity Providers & Authentication Configuration
Key Takeaways
- Power Pages external authentication decouples external user access from internal Dataverse user licenses: every authenticated portal user maps directly to a 1:1 Contact record in Dataverse.
- External identity provider tokens (subject GUIDs/object IDs) are persisted in the adx_externalidentity table, linking external claims to the corresponding Dataverse Contact record.
- Power Pages natively supports modern identity providers including Microsoft Entra ID, Microsoft Entra External ID (Azure AD B2C), Google, LinkedIn, Facebook, and standard OpenID Connect (OIDC) / SAML 2.0 protocols.
- Portal registration workflows are governed by Site Settings: Authentication/Registration/OpenRegistrationEnabled enables public sign-ups, while InvitationEnabled restricts access to pre-issued invitation codes.
- Portal Invitations (adx_invitation) allow organizations to onboard users by pre-assigning Web Roles, pre-populating Contact attributes, and delivering single-use secure redemption URLs.
External Identity Providers & Authentication Configuration
A critical value proposition of Microsoft Power Pages is its ability to provide secure, authenticated access to external stakeholders without requiring expensive internal Microsoft 365 or Power Apps per-user licenses. To achieve this, Power Pages implements a standards-based authentication architecture that integrates with enterprise identity providers (IdPs), social networks, and customer identity solutions.
For the PL-200: Microsoft Power Platform Functional Consultant exam, you must master how external users are mapped to Dataverse Contact records, how to configure external Identity Providers (including Microsoft Entra ID and Entra External ID / Azure AD B2C), how to control registration behaviors using Site Settings, and how to execute secure Portal Invitation onboarding workflows.
1. Portal Authentication Architecture & Contact Mapping
Power Pages strictly separates internal staff (who authenticate as systemuser records using internal Entra ID organizational accounts) from external portal visitors. Every external authenticated portal user is represented as a Contact (contact) record in Dataverse.
+-----------------------------------------------------------------------------------+
| POWER PAGES IDENTITY MAPPING ARCHITECTURE |
| |
| [EXTERNAL USER / BROWSER] |
| │ |
| ▼ 1. Authenticates against external IdP (Entra ID, B2C, Google, OIDC) |
| [IDENTITY PROVIDER] ───> Issues Identity Token (Issuer + Subject OID / Claim) |
| │ |
| ▼ 2. Token passed to Power Pages Portal Engine |
| [adx_externalidentity TABLE] |
| ├── Identity Provider Key (e.g., https://login.microsoftonline.com/...) |
| ├── Username / Subject ID (e.g., 8f7b2c14-55d6-4a92-...) |
| └── Lookup to Contact (contactid) |
| │ |
| ▼ 3. Resolves 1:1 Contact Record |
| [DATAVERSE CONTACT RECORD] ───> Linked to Web Roles & Table Permissions |
+-----------------------------------------------------------------------------------+
The adx_externalidentity Table
When a user signs in through an external identity provider, Power Pages does not store their password in Dataverse. Instead, the portal engine queries the External Identity (adx_externalidentity) table to map the external identity claim to a Dataverse Contact:
- Identity Provider (Issuer): Stores the unique URI identifier of the IdP (e.g., Azure AD B2C authority or Google issuer).
- Username / Subject ID: Stores the unique Object Identifier (OID) or sub claim provided in the IdP's JWT token.
- Contact Lookup: Links directly to the matching
contactrecord.
[!NOTE] Multi-Provider Linking: A single Dataverse Contact record can have multiple linked
adx_externalidentityrecords. This allows a customer to sign in interchangeably using their corporate Entra ID account, Google account, or LinkedIn profile while maintaining a single unified portal profile and transaction history.
2. Supported Identity Providers & Protocols
Power Pages supports modern authentication protocols configurable through the Set up workspace in Power Pages Design Studio or via Site Settings in the Power Pages Management app:
+-----------------------------------------------------------------------------------+
| SUPPORTED IDENTITY PROVIDERS |
| |
| [ENTERPRISE DIRECTORIES] [CUSTOMER IDENTITY (CIAM)] |
| - Microsoft Entra ID (Azure AD) - Microsoft Entra External ID (Azure AD B2C) |
| - Single & Multi-Tenant - Custom User Flows & MFA |
| |
| [STANDARD PROTOCOLS] [COMMERCIAL & SOCIAL] |
| - OpenID Connect (OIDC) - Google, LinkedIn, Microsoft Account (MSA) |
| - SAML 2.0 - Facebook, Twitter (X) |
| - WS-Federation |
+-----------------------------------------------------------------------------------+
Identity Provider Types & Characteristics
| Identity Provider Type | Primary Protocol | Best Use Case | Key Configuration Parameters |
|---|---|---|---|
| Microsoft Entra ID | OpenID Connect | B2B partner portals, vendor access where external partners already have Microsoft organizational accounts. | Authority, ClientId, ClientSecret, RedirectUri |
| Microsoft Entra External ID (Azure AD B2C) | OpenID Connect | Recommended for B2C customer portals. Highly scalable consumer identity management with self-registration, password reset, and MFA user flows. | Authority, ClientId, RedirectUri, SignUpSignInPolicyId, ResetPasswordPolicyId |
| OpenID Connect (Generic) | OIDC / OAuth 2.0 | Integrating with third-party enterprise IdPs like Okta, PingFederate, Auth0, or custom OAuth servers. | MetadataAddress, ClientId, ClientSecret, Scope |
| SAML 2.0 | SAML 2.0 WebSSO | Legacy enterprise SSO federations (e.g., Active Directory Federation Services - ADFS, Shibboleth). | MetadataAddress, ServiceProviderEntityId, AssertionConsumerServiceUrl |
| Social Providers | OAuth 2.0 | Public citizen portals, consumer feedback sites (Google, LinkedIn, Facebook). | ClientId (App ID), ClientSecret (App Secret) |
3. Site Settings for Registration & User Lifecycle
Authentication behavior in Power Pages is governed by key Site Settings stored in Dataverse. These settings control whether registration is public, invitation-only, or disabled, and enforce credential security standards.
+-----------------------------------------------------------------------------------+
| PORTAL REGISTRATION SITE SETTINGS |
| |
| [Authentication/Registration/Enabled] ─────────────────> Master registration on |
| |
| [Authentication/Registration/OpenRegistrationEnabled] ─> Allow public sign-up |
| without invitation |
| |
| [Authentication/Registration/InvitationEnabled] ───────> Allow redeeming |
| invitation codes |
| |
| [Authentication/Registration/LocalLoginEnabled] ────────> Allow local username/ |
| passwords in Dataverse |
| (RECOMMENDED: FALSE) |
+-----------------------------------------------------------------------------------+
Key Authentication Site Settings
| Site Setting Key | Default Value | Functional Impact & Best Practice |
|---|---|---|
Authentication/Registration/Enabled | true | Enables or disables all registration workflows on the portal. If false, no new users can register under any mechanism. |
Authentication/Registration/OpenRegistrationEnabled | true | If true, any visitor can register and create a portal account. For private or restricted portals, set to false to prevent unauthorized sign-ups. |
Authentication/Registration/InvitationEnabled | true | Enables the /Register?invitation= endpoint, allowing users to redeem secure invitation codes. |
Authentication/Registration/LocalLoginEnabled | false (modern) | Controls whether users can create a local username and password stored in Dataverse. Security Best Practice: Set to false in production to eliminate local credential storage risks and mandate modern IdPs with MFA. |
Authentication/Registration/RequiresConfirmation | false | When set to true, requires the user to click a confirmation link sent to their email before their account is activated. |
Authentication/Registration/RequiresUniqueEmail | true | Enforces that no two Contact records can register using the same email address. |
Authentication/Registration/RememberBrowserEnabled | true | Allows persistent authentication cookies across browser sessions. |
4. Portal Invitation Onboarding Lifecycle
When organizations need to onboard specific external partners, contractors, or VIP clients into a secured portal, they utilize Portal Invitations (adx_invitation). This ensures that only pre-approved individuals can access the site, while automatically granting them the correct Web Roles and linking to existing Dataverse records.
+-----------------------------------------------------------------------------------+
| PORTAL INVITATION REDEMPTION LIFECYCLE |
| |
| [1. CREATE INVITATION RECORD] |
| ├── Target Contact: Links to existing Contact (Jane Doe) |
| ├── Pre-Assigned Web Roles: Assigns 'Partner Admin' role |
| ├── Type: Single-Use (Individual) or Group Invitation |
| └── Generates unique Invitation Code (e.g., A7X9-K2M4-P8Q1) |
| │ |
| ▼ |
| [2. DELIVER INVITATION EMAIL] |
| └── Sends link: https://portal.contoso.com/Register?invitation=A7X9-K2M4-P8Q1 |
| │ |
| ▼ |
| [3. USER REDEEMS INVITATION] |
| ├── Clicks link and selects external IdP (e.g., Entra ID / B2C) |
| ├── Authenticates successfully with external credentials |
| ├── System creates adx_externalidentity record linked to Jane Doe |
| ├── System assigns 'Partner Admin' Web Role to Jane Doe |
| └── Invitation record status transitions to 'Redeemed' |
+-----------------------------------------------------------------------------------+
Invitation Configuration Options
-
Single-Use vs. Group Invitations:
- Single-Use (Individual): Linked to a specific pre-existing Contact record. Can only be redeemed once. Once redeemed, its state changes to
Redeemedand cannot be reused. - Group Invitation: Not linked to a pre-existing Contact. Allows a specified maximum number of redemptions, creating a new Contact record for each user who redeems the code.
- Single-Use (Individual): Linked to a specific pre-existing Contact record. Can only be redeemed once. Once redeemed, its state changes to
-
Automatic Web Role Assignment:
- Consultants associate one or more Web Roles directly to the Invitation record.
- The moment the invitation is redeemed, the portal engine automatically writes the association to the
adx_webrole_contacttable, immediately granting the user their authorized permissions.
-
Account Association:
- If the target Contact is already linked to a parent
account(e.g., "Fabrikam Inc"), all Account-scoped Table Permissions become active immediately upon redemption.
- If the target Contact is already linked to a parent
5. Portal User Profile & Lifecycle Management
Once registered, external user accounts must be maintained throughout their lifecycle:
-
Profile Page Management:
- Power Pages includes a built-in Profile web page (
/profile) where authenticated users can view and update their personal information (First Name, Last Name, Email, Phone Number, Preferred Language). - Changes made on the Profile page update the underlying Dataverse
contactrecord in real time. - Profile completion can be made mandatory before accessing other site pages via the
Authentication/Registration/ProfileRedirectEnabledsetting.
- Power Pages includes a built-in Profile web page (
-
Deactivating / Revoking Portal Access:
- To immediately revoke a user's portal access without deleting historical transaction data:
- Method 1 (Deactivate Contact): Deactivating the
contactrecord in Dataverse immediately blocks all authentication and table access. - Method 2 (Revoke Web Roles): Removing the user's custom Web Roles restricts them to baseline Authenticated Users permissions.
- Method 3 (Delete External Identity): Deleting the corresponding row in
adx_externalidentitybreaks the link between their external IdP and the Dataverse Contact record.
- Method 1 (Deactivate Contact): Deactivating the
- To immediately revoke a user's portal access without deleting historical transaction data:
A financial services organization is building a customer portal using Power Pages. For security and compliance, the organization mandates that external users must never create or store passwords in Dataverse. Instead, customers must sign in using a consumer identity platform that supports multi-factor authentication (MFA), self-service password reset, and customizable sign-up user journeys. Which identity provider should the functional consultant recommend?
An enterprise wants to onboard 50 authorized supplier representatives to a private Power Pages vendor portal. To prevent unauthorized access, public self-registration must be disabled. Each supplier representative already has a Contact record in Dataverse with their corporate email and assigned company Account. The representatives must receive an email containing a link that automatically links their corporate Microsoft account to their existing Contact record and assigns them the 'Supplier Admin' web role upon sign-in. How should this be implemented?
A portal administrator notices that external users are creating multiple accounts with local usernames and passwords directly on the portal, bypassing the corporate Entra ID single sign-on requirement. Which Site Setting in the Power Pages Management app must the consultant update to disable local credential creation?
An external user signs into a Power Pages customer portal using their Google account for the first time. How does the Power Pages architecture establish and maintain the link between the external Google user and the user's records in Dataverse?