If you'd like a deep dive into specific areas within Power Apps portal security, Microsoft Docs is the ultimate, so I am making no attempts to replace our existing documentation. That said, when we're new to an area such as Power Apps portals, it can be helpful to get a higher level and snapshot view. Here I've broken it down into a 101-level primer.

How do users access the Power Apps portal?

When planning for your portal deployment, one of the first questions that will inevitably be asked is-- Will your end-users be logging into the portal and be treated as authenticated users, or will they be accessing anonymously as guests? Power Apps portal supports both scenarios, and you can even use a combination of the two. If you will be requiring or allowing users to register and login to the portal, various external identity providers are available for configuration.

Power Apps portal users are not Dynamics users!

Power Apps portal is meant to extend your Dataverse data to an external audience--- this means that a portal user is not the same as a Dynamics 365 / Model-driven app user. In fact, if you do have Dynamics 365 users that are using the portal, their security roles and business unit are not going to apply here.

The website is on a separate security model from what Dynamics 365 administrators may be accustomed to. This is because Power Apps portal users are treated as contact records in Microsoft Dataverse. When a user registers for the portal --or signs in if they are using Azure AD-- a contact record is created in Dataverse. If the contact record already exists in Dataverse, they can be invited to the website using out of the box functionality. The contact record will then store the portal user's identities and web roles.

Web Roles

To reiterate, Dynamics 365 security roles will not apply to the portal! Granted, the general concept is not too different here. In the website's case, a user's persona is defined by the Web Role(s) that they have been assigned. Web Roles themselves will not have permissions stored on its record. Rather, think of a web role as a container table for permissions. It is only the web role that is then directly assigned to users-- or rather, contact records.

Page Permissions*

The portal is a website; it has web pages! Naturally, we are able to specify permissions at the web page level. We can use permissions to restrict user access to certain pages to those that are logged in or who may have a specific web role. If applied, a user who does not have access to a certain web page will neither be able to see the web page in the navigation menu nor will the user be able to navigate directly to its URL without it erroring out. In a hierarchical setting, page permissions can also be used to secure entire branches of a website through inheritance.

Table Permissions*

If we've opted to implement the portal, chances are that we have done so in order to extend our Dataverse data to an external audience. If that's the case, then we need to ensure that we're taking into account our security at the table level. Table permissions are what determine the CRUD actions that users can take on specific records. Yes, that means that we can indeed apply long sought-after record-level security here, which is done via Dataverse relationship definitions.

Realistically, you are going to be using a combination of page and table permissions. We may need to restrict users from specific web pages or branches of the website. If web pages contain Dataverse table data, then we also need to ensure that said table has been secured with table permissions.

Tip: Table permissions will not apply unless you check the box "Enable Table Permissions" on its respective table form and table list.

*Page permissions are formerly known as Web Page Access Control Rules

*Table permissions are formerly known as Entity permissions

 Power Pages: How a Microsoft Cloud Solution Architect can help

Skylar Shonblom