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.

Unprotected PowerApps Portal Page

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.

CDS Contact record with web authentication details

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.

PowerApps Portals Login Page

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.

Instructor Web Role

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

Web Role assigned to Contact

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”.

Web Page Access Control Rule

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

Web Roles assigned to Web Page Access Control Rule

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.

Web link not visible due to Web Role
Web Link Visible to logged in Portal user

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.

Entity List filtered by logged in Portal User

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 List showing only related CDS data

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.

Setup Entity Permissions with scope set to Contact

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

Blocked due to entity 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.

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

  1. This is great. I am coming from the land of SharePoint and so was curious as to the security trimming of links in particular.

    The features offered by PowerApps Portals and Model Driven Apps are just amazing, aside from your own fantastic blog are there any other resources I could use to get up to speed? Would it be worthwhile to go through all of the existing Dynamics Portals documentation as we await more and more PowerApps Portals documentation?

    Like

    1. Most of the Dynamics 365 Portals or Adxstudio documentation, blogs, videos, etc. still apply to PowerApps Portals. Here are some links to MS Learn that are near impossible to find via a search but are great resources (full disclosure -> I helped with some of the content)

      https://docs.microsoft.com/en-us/learn/paths/extend-dynamics-365-portals/
      https://docs.microsoft.com/en-us/learn/paths/work-with-portals-in-dynamics-365/
      https://docs.microsoft.com/en-us/learn/paths/get-started-dynamics-365-portals/

      Blogs:
      https://colinvermander.com/
      https://www.engineeredcode.com/blog

      I also teach a Portals Masterclass, Currently, have one tentatively scheduled for the UK in October. My goal is to have this as an online course before end of the year. https://www.expertcrm.co.uk/courses/dynamics-365-portals-jump-start/

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s