Identity Strategy for Power Pages

For the Power Pages implementations, choosing Identity Strategy is an important first step and is critical for the success of the implementation. This blog post provides guidance for anyone implementing Power Pages on authentication flow (including identity provisioning, registration process, identity mapping) with suggested best practices. With this guidance you would be able to decide the best available option for your Power Pages Identity scenarios.

Please note that Power Pages Sites can also be available anonymously and for those scenarios no authentication is needed. Please follow the guidance on our best practices to lock down the content for Anonymous users.

Pre-requisites: Before going into identity strategy, let's understand how and what user information is stored in the Power Pages. 

Authentication is the process of validating the user’s identity i.e., a verification of who they say they are. In Power Pages, each authenticated user is associated with a contact record in Dataverse, that means the Contact record must exist in Dataverse. Once the contact is created an identity is associated with the contact (Local or External Identity). This is needed for user authentication. With this configuration in place a Power Pages (Portal) user can login and complete the Authentication.

Authorization is the process of verifying that the user has access to something, determining “if they can do x” i.e., the content the authenticated user is authorized (allowed to see) is driven by web roles. In Dataverse, Contact would be associated to a web role, and this controls the content the user can have access to. Usually, the web role assignment happens during user provisioning or registration process.

We will not go into the authorization part i.e., web roles and table permissions in this article but will concentrate on the authentication piece of the Power Pages.

Authentication: Power Pages Portal Authentication involves two steps:

1. Create Contacts in Dataverse

2. Associate Identity providers with the contact (Please note there can be multiple identity providers for a contact, however you can have only one instance of each identity provider type for OAuth2.0 such as Facebook, LinkedIn, Google, Twitter and Microsoft). This association can happen when a user registers or can be created manually to migrate existing users.

Power Pages has a unique feature where one user(contact) can use multiple identity providers to login. In case, if you allow multiple identity providers to access your portal there will be one contact with multiple external identity records.

Identity Provisioning: In this context (for Power Pages), identity provisioning is the process of creating a contact and associating identity information. First and foremost, solution architects should think about the target audience i.e., who the portal users are. Second consideration is the strength of identity needed per IT/Security team requirements.

First, decide the Target Audience Types:

• Business to Consumer (B2C): Providing access to your business data to the end users. Sample use cases include creating support cases, exposing knowledge base, ability to view/show customer's order info etc.,
• Business to Employee (B2E): HR based portals or Department related portals.
• Business to Business (B2B): Partner based portals and multi-tenant-based portals.

The second step is to take into consideration the strength of identity needed by deciding how these audiences can login/register i.e., to define the identity provider based on the target audience type.

1. Understand the type of audience i.e., B2C vs B2E vs B2B and available identity provider options.
2. Based on the audience type, select the identity provider.
   • B2C (Business to Consumer): Social Identity Providers (OAUTH), Identity Services (Azure AD, Okta, Auth0) or Application-specific (Local auth) 
   • B2E (Business to Employee): Identity services (Azure AD, Auth0 etc.), OIDC, SAML 2.0 Compliant identity providers 
   • B2B (Business to Business):  Identity services (Azure AD, Auth0 etc.), OIDC, SAML 2.0 Compliant identity providers 
3. Define the registration and/or invitation flow.

Currently there are two authentication methods as specified below:

• Local Authentication: Forms based, username and password are stored in Dataverse on contact. Although this is an option now, we do not suggest using this and recommend using a username / password-based authentication via Azure AD B2C. Azure AD B2C is a robust identity provider service that can provide sophisticated features like MFA (multifactor authentication), setting password complexities, mitigating credential attacks etc. 
• External Authentication:  When external authentication is used, credentials and password management are handled by external identity providers. Supported authentication protocols include:

Microsoft recommends customers to move from Local Authentication and switch to Azure AD B2C.

As we are recommending the customers to move away from local authentication with Dataverse to external identity providers it is important to understand the underlying authorization flow. Portal authorization flow is based on OAuth flow with implicit grant.

1. When a user logs in via Power Pages Site, the browser will redirect the user to the identity provider site. To make this redirect a one-time configuration must be done where we need to specify the client id, request type, scope, and redirect URL. (An Azure AD application needs to be created that will generate the client id. Specify the request type, scope and redirect URL within the Azure AD application)

2. User enters the login credentials and submits to the identity provider. The user provides their consent during the first login. Identity provider validates and sends the access token and id token which contains claims for the requested scope to the redirect URL specified in step 1.

3. Power pages does identity mapping based on the claims available. Email claim present in the token/SAML response is used to do the mapping. Email claim is any claim with name as either “email”, “emails” or “upn” and is looked up in that order. If multiple of these are present, the first one is picked up in the order described above and the rest are discarded.

4. Once the email claim is found and email address extracted from it, all contacts are searched for a matching email in “primary email address” i.e., emailaddress1 field of the contact. If a unique match is found, the user is associated with it. If there is no match, a new contact is created, and an associated external identity is created. In case if multiple matches are found an error message will be shown.

Standard Sign-in flow:

To configure the external identity provider, please refer to the following docs.

• https://learn.microsoft.com/en-us/power-apps/maker/portals/configure/configure-portal-authentication
• https://learn.microsoft.com/en-us/power-apps/maker/portals/configure/use-simplified-authentication-configuration

Registration Flow: After selecting the identity provider (derived from the type of audience), the next step is to define the registration flow. There are a few options available to register the users.

Open Registration: Any one can visit the Power Pages and register themselves using the identity provider registration flow. The following site setting would enable the open registration.

• Authentication/Registration/OpenRegistrationEnabled – true

This is the most common for B2C portals like creating a portal for external customers. In this approach any user can login to portal if they have a valid account with the identity provider used. For example, If Facebook is enabled as auth provider, anyone with Facebook ID can login or they can register a new account of Facebook and register.

Invitation Based Registration: Users of the Power Pages Portal are invited via invitations. In this flow, the users that need to be invited to the portal are created as contacts in the Dataverse. Then an invitation is created via Power Automate flow and sent to the users to redeem. You can also leverage the invitation process using Azure AD B2C.

Potential factors that can assist to define the optimal user registration process is below:

1. Is there an existing user store? Can we leverage that store? (For example: Existing Database with user information) – This step is for creating contacts in Dataverse.

   1. If there is an existing user store (legacy database etc.) with all the users, consider migrating them. The advantage is the users do not have to provide information they already have provided before. Dataverse contacts can be quickly populated with users from legacy databases. (Please refer to the identity migration section below to see available options)

   2. The solution architects need to evaluate and carefully consider the pros and cons of each approach. 

      • Local Authentication: Consider carefully the liabilities associated with storing login credentials within Dataverse (i.e., local authentication - where user information along with hashed password is stored in Dataverse). Important: We recommend customers to avoid using Local Authentication and consider other options like Azure AD B2C 

      • External Identity Providers: Power Pages supports external identity providers, several identity providers that you can configure are added by default. You can add additional Azure AD B2C Providers or configure the available OAuth 2.0 providers or 3rd Party Identity providers that support OIDC.

2. Existing Identity Service (Azure AD, OAUTH2.0, OCID or 3rd Party Providers): Consider the following to leverage existing identity service for authentication.

   1. If you choose to leverage an existing external identity service, consider the strength of the identity issued by that service and make sure it meets IT and Security teams requirements as well as the availability and scalability of the service.

   2. Power Pages support any identity provider that is built on OAuth 2.0 or OIDC Protocols.

   3. For internal or corporate users, you can also use Azure AD integration available out of the box.

3. New Power Pages Portal - No existing user repo or Identity Service

   1. Create a registration flow that works best for your scenario.

   2. Send an invitation email to the user after the contact is created. (In the invitation email, you could use the sign-up flow you would define in the identity provider)

   3. Let the user redeem the invitation (associates the identity to the contact entity)

Note: Power Pages supports a configurable security system that lets your customers support multiple authentication systems. Going forward, we recommend that you use only Azure AD B2C identity provider for authentication and that you deprecate other identity providers.

 Migrate identity providers to Azure AD B2C - Power Apps | Microsoft Learn

Identity Migration: (Applicable to scenarios with existing user store or existing Identity service)

1. Bulk User Migration with contact creation: Recommended pattern is to extract the user's data, minus the passwords or hashed passwords from the legacy system into Dataverse. (Create contacts with the available information). Once you have the contact in Dataverse there are multiple options to have the user’s sign-up and associate to the existing contact.

1. Invitation Flow: Use the invitation flow available in the Power Pages to send each user an invitation to redeem. This method works with both local as well as external Identity providers. The invitation flow allows you to send specific invitations to users (contacts) in Dataverse.  https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/set-authentication-identity#redeem-an-invitation 
2. Send a password reset link.

2. The pros with this approach are you can transfer all users at once before switching to the Power Pages and the cons include you will end up asking all users to redeem or reset the new password, even inactive accounts are transferred to the Power Pages. Note: Depending on the type of identity provider you choose, you can leverage the Sign in and sign-up flows or password reset flow provided on the identity provider.

3. User migration with external identity creation: This is only applicable for external Identity providers. In this method, external identity records are created along with the contacts.

1. Migrate existing users from the current system to Dataverse as contacts.
2. For each contact, create (and associate) an external identity record with values as below:
   1. Username – Unique Identifier in IDP (sent as sub claim by IdP, in case of Azure AD or Azure AD B2C this would be objectid)
   2. Identity Provider – This is the issuer in case of Open ID connector providers. For Azure AD, this is in the following format.
      1. https://sts.windows.net/{tenant id}
   3. On each contact record, set following fields as well
      1. Username -> Same as Username of external identity record
      2. Login Enabled -> True
      3. Security Stamp -> Set as a random GUID
      4. Email Confirmed -> True
      5. Lockout Enabled -> True
   4. One this is done, when a user logs in, his external identity details will be matched automatically, and user would be able to login to the portal.

        Note: You can control the ability to register to the portal through registration flow by using the following site setting:

• Authentication/{Protocol}/[Federation-Name]/RegistrationEnabled
  • If set to false – Open Registration is not allowed.
  • If set to true – open registration is enabled, and anyone can register.

 Identity mapping: (with an Identity Provider):

1. Identity provider is the service that authenticates the user and provides the user identity information (by issuing claims about their identity and attributes) to Power Pages. When a user attempts to access Power Pages using an identity service, they are redirected to the Identity Provider (IDP), where they are required to enter their login credentials. If their credentials are valid, the IDP sends a message to the Power Pages indicating that the user has been authenticated, and Power Pages grants access. Identity provider also issues a token containing claim(s) about the user identity.

2. After the users log in, email claim present in the token/SAML response is used to do the mapping. Email claim is any claim with name as either “email”, “emails” or “upn” and is looked up in that order. If multiple of these are present, the first one is picked up in the order described above and the rest are discarded.

3. Once the email claim is found and email address extracted from it, all contacts are searched for a matching email in “primary email address” field of the contact. If a unique match is found, the user is associated with it. If a unique match is not found, a new contact is created along with the associated external identity record.

Single Sign On:  Power Pages support Single Sign On with multiple identity providers. To achieve this, proper planning and configuration is needed (as this does not work by simply toggling a setting or a button). Power Pages do not take tokens, cookies, certs, or sessions to somehow sign-in users nor there is a feature or script for coding a single sign-in. In general, IdP supports SSO in the same browser session and Portal cannot control this.

To configure Single Sign on, you must initiate authentication flow by, sending the user to a web page that requires authentication to initiate authentication flow which then takes them to Sign-in page which then can take them to IdP, where the IdP would authenticate or recognize a previous active session, passing back to us authenticated context and then we navigate the users to a web page as authenticated user.

Common Identity Scenarios:

1. Azure AD User Login – Can leverage the existing Azure AD User directory (used by Office 365 and Dynamics 365 Users). This can also be applicable in the case of Federated or B2B scenarios including guest users. Azure AD can support the following:
   1. Single tenant authentication
   2. Multi-tenant authentication
      1. A new Azure AD App needs to be registered.
      2. Azure AD multi-tenant setting must be turned on.
2. Azure AD B2C User Login – Can also create a new Azure AD B2C directory separate from the existing Azure AD and have Authentication through B2C. This will offer multiple options if you want to expand to other providers or other businesses.
   1. Supports single tenant as well as multi-tenant.
3. 3^rd Parth Identity Providers:
   1. Supports SAML 2 or OpenID

Frequently Asked Questions:

1.  Does Azure AD B2C support custom policies?

   1. Custom polices are supported in the same way as user flows. The easiest way is to create a user flow and test the flow. This will create all the necessary site settings within the Power Pages Site. Replace each site setting with the custom policy values and test the flow.
   2. Useful Resources:
      • Configure the Azure Active Directory B2C provider manually - Power Apps | Microsoft Docs
      • Configure site settings for portals - Power Apps | Microsoft Docs
      • Tutorial - Create user flows and custom policies - Azure Active Directory B2C | Microsoft Docs
      • Power Pages Authentication with B2C Custom Policy - Microsoft Dynamics Blog

2. How to configure SSO with Power Pages?

   1. Set up a web page access rule for your home page with restrict read rights and for role select authenticated users. This will restrict access to unauthenticated users and as soon as the user navigates to the homepage it will automatically be redirected to the sign-in page.
   2. Authentication/Registration/LoginButtonAuthenticationType: If a portal only requires a single external identity provider (to handle all authentication), this allows the Sign-In button of the header nav bar to link directly to the sign-in page of that external identity provider (instead linking to the intermediate local sign-in form and identity provider selection page). Only a single identity provider can be selected for this action. Specify the AuthenticationType value of the provider.
   3. For a single sign-on configuration that uses OpenID Connect, such as Azure AD B2C, the user needs to provide the Authority.
   4. For OAuth 2.0–based providers, the accepted values are: Facebook, Google, Yahoo, Microsoft, LinkedIn, or Twitter
   5. For WS-Federation–based providers, use the value specified for the Authentication/WsFederation/ADFS/AuthenticationType and Authentication/WsFederation/Azure/[provider]/AuthenticationType site settings.
   6. Examples: https://adfs.contoso.com/adfs/services/trust, Facebook-0123456789, Google, uri:WindowsLiveID.

Hope this guidance will help to decide the best available option for your Power Pages Identity Scenarios!

We would like to acknowledge the work of MVP Yannick Reekmans and his amazing presentation at the Microsoft Power Platform Conference. His session served as a pivotal source of inspiration for this article and reference materials for the diagrams used in this article which help easily explain complex subject matter.