PowerApps Portals: How to Hide or Show Content based on Logged in User

For those just starting out configuring PowerApps Portals, the question will eventually come up as to how to show or hide content based on the logged in user.

For example, if you are showing a page with registration to a private event or showing user specific data like support cases or invoices.  You will want to ensure that this CDS based data is not exposed to the general public.

In this example I have setup a “super secret” web page and I want to limit who can actually see it and the data.

User Authentication

The first thing to consider is user authentication. This is the process of allowing someone from the outside world the ability to login to your portal, typically with a username and password.

The way authentication works in PowerApps Portals is that every authenticated portal visitor (users that will login to the portal using some kind of credentials) must have a corresponding CDS Contact record. 

By default, PowerApps Portals are configured to automatically use forms based authentication. 

An anonymous portal visitor can register on the portal, which will create a contact record, that will store a username and an encrypted password. 

Alternatively, an existing contact in the CDS/Dynamics 365 system can be given an invitation code that can be used to associate the existing contact to a portal login and password.

Using Site Settings, you can configure the various aspects of the registration/authentication experience for you portal depending on requirements.  For example, you may not want to allow anonymous portal visitors to create user accounts, or you may want to force the users to use their email address as a portal login.

The recommended method for authentication is to configure Azure AD B2C and not use the out of the box forms authentication.  I recently wrote a post how to setup PowerApps Portal Authentication using Azure AD B2C.

Web Roles

A contact can be assigned a web role.  A web role is very similar to a CDS security role that we would assign to a user.  When a portal is provisioned, the administrator, authenticated users and anonymous users web roles are created.  You can also create your own custom web roles.  For the most part, you would assign a contact to the web role much like a CDS user is assigned a security role for specific privileges. 

The exceptions are if the web role has been marked as “authenticated users” or “anonymous users” which means that it is implied that either (or both) authenticated and anonymous users

In our example, I have created an Instructors Web Role.

Once the Web Role is created, it can be assigned to the Contact record.

Web Page Access Control Rule

There are two different features of the Portal that are used to protect content and data.  The first concept is the Web Page Access Control Rule.  This is linked to a web page record and also linked to a particular web role.  The web page access control rule can be set to levels or privileges, “restrict read” which basically means any portal contact with a web role linked to the web page access control rule can “read” the web page on a portal.  The other is “Grant Change” which means that users have the ability to modify any of the editable static content (content snippets, page title, page copy, etc) from the legacy front side editing tools, if they have the content editor permissions.  For the most part, if you want to allow a user to view or not view the page, choose “restrict read”.

Once the Web Page Access Control Rule is created, then assign specific Web Role(s).

If a portal user belongs to the particular web role, linked to a web page access control rule with “restrict read” permission, they can view the particular web page and the corresponding web link will be visible in the menu for that user for that web page, but it will not be visible to anyone else.

If you just want to restrict access to a page, then web page access control rule is all you need.

Note: You can still show the web link to a protected page by selecting “Disable Page Validation” in the web link record’s Link Options section. The portal user will still need to login to access the page.

However, you might want to limit visibility to specific data in an entity list, entity form, web form or some other method of dynamic content (e.g. retrieving data via a Liquid/FetchXML)

While you can filter an entity list via a relationship to the contact (current user) this still won’t necessarily completely protect your data.

Once the filter is setup, the logged in Portal user will only see records in an entity list that apply to them based on the filter.

Entity Permissions

Setting up Entity permissions links a specific CDS entity to a web role.  On the entity permission record you can specify the scope and permissions.  This will allow you to secure CDS data on the portal.

For example, if you did not protect a specific entity with a corresponding entity permission record, if you could determine the GUID of specific record you, could still manipulate the URL to view data (hack) on the portal.

With entity permissions enabled, you would be not be able to view the record. The entity permission record specifies the entity, the scope and the privleges.

Once the entity permissions are setup, attempting to hack to the entity form page again will prompt the user that they do not have permissions

By default, any dynamically generated content (via Liquid) is automatically protected by entity permissions.  For data surfaced on entity forms or entity lists, you do need to enable the entity permission check box.

A full overview of entity permissions on PowerApps Portals will be the topic of a future post.

Cover Photo by marcos mayer on Unsplash

Summary

Protecting and securing data is critical for any business system, apps built on PowerApps Portals are no exception. Using web roles, web page access control rules and entity permissions allows portal makers to be able to easily and consistently build an app where the data is secure.

Nick Doelman is a Microsoft Business Applications MVP and has presented sessions and classes on PowerApps Portals around the world. Follow Nick on twitter at @readyxrm.