Okay, let’s confront the elephant in the room… permissions and security trimming aren’t the most exciting topic when learning about portals – especially if you arrived here as part of your journey into mastering the Portal Web API. However, there’s no denying the fact that they’re absolutely necessary and foundational to a successful portal project that provides secure access to your organisation’s precious data and processes… so keep on reading!

In this write-up, I compare portal security to analogies from the security model in Dynamics 365 and model-driven apps. If you aren’t yet familiar with those, I highly recommend you start by reading Paddy Byrne’s excellent content on Securing the Dataverse over at Virtual Power Group

Otherwise, here are some analogies you might find helpful:

• Each table permission is like a key
• A web role is like a set of keys (each portal ‘user’ we assign this web role to gets all the table permissions associated with it… all the keys in the set)

Similar to the security roles and privileges you’d configure and apply to users within Dynamics, table permissions and web roles allow us to apply ‘Record-level’ and ‘role-based’ security for portals.

Users and ownership in Dynamics vs Contacts and relationships in Power Pages

One key difference is that the privileges within a Dynamics 365 security role are dictated based on ownership – the relationship a user, their team, business unit or organisation has with records in a particular table. Users and ownership mean nothing in the context of portal security.

As you may be aware, portal ‘users’ are actually Contacts and the basis of row based security is the relationship that the logged in contact (or their account) has with the record.

For example, when we log in to online banking, we expect to see the equivalent of contact scope; the balance and statements for our own bank accounts only, and that no other customers get to see information about our bank accounts. If we have a business or joint account, perhaps we’d open up the data model so that multiple contacts could have a relationship to the bank account

In order to be security-trimmed on the portal, each table must either:

• Have a direct relationship (eg a lookup or a many-to-many relationship) to the Contact or to the contact’s Account record (e.g. a case where either the contact or its parent account are selected in the Customer field)
• Be the child of a record that has a direct relationship to the Contact or Account table (think notes and/or activities related to a case)

Table Permissions

Table permissions are equivalent to the table-level privileges within a security role in Dynamics. Here we determine what anyone with the selected web role(s) is permitted to ‘do’ with those records:

• Read
• Write
• Create
• Append
• Append To

Note – I go into these in more detail shortly, right after ‘access types’…

Access Types

The Access Types for Table Permissions are similar to the level for privileges within Dynamics / Model Driven App Security Roles:

Privilege levels for a Security Role in Dynamics:

Access Types for a Table Permission in Power Pages: 

Global access type is similar to Organisation level privileges

Account access type is similar to Business Unit level privileges in that the user / contact doesn’t necessarily own the record directly but the contact belongs to the team / company that does ‘own’ the record

Contact access type is equivalent to User level privileges

Tip: If in doubt, follow the trail back to the contact

Once the access type is defined, privileges allow you to control the level of access they have to their records – what can they ‘do’ with those records?

Note: Table permissions are more granular than security roles. Unlike security roles, granting table permissions, let’s say notes regarding cases where I am customer (a child permission of  ‘cases where I am customer) is specific to that relationship only and doesn’t mean the user then has permissions to see all notes ‘across the board’ (such as notes regarding opportunities where I am customer, notes regarding my contact record or even ‘orphaned‘ notes).
You’ll need to set up separate permissions for each relationship e.g. access to notes related to Cases within contact access type doesn’t provide that same contact access to notes relating to Opportunities, etc.

What about lookup columns? Are they a pain?

Example: I need to populate the Customer column on a case

The portal user needs a web role with permissions to:

• Read, Create / Edit and Append To the Case table

AND

• Read and Append privileges on the Contact and Account tables

So that’s how we define the permission but how do we give someone those privileges?…

Web Roles

The Web Roles list allows you to specify which web roles a portal user must have in order to receive this table permission.

It’s very important that you remember to select one or more web roles otherwise the permission isn’t applied to anyone.

Where table permissions are like privileges within a security role, a web role is the equivalent to a security role.

By default, the portal solution includes 3 web roles; authenticated users, anonymous users and administrators:

Out of the box web roles

• Anonymous users (any visitor that hasn’t logged in. This role might be useful for lead generation or a contact form.
  Note – Even registered users that are yet to sign in are treated as anonymous.)
• Authenticated users (contacts that have logged in to the portal)
• Administrators (enables front-end editor and ability to refresh the cache and rebuild search index)

There’s nothing you need to do to manually assign someone the anonymous users or authenticated user web roles, they’re given automatically based on whether the user (Contact!) is logged into the portal. However, you need to decide who you wish to give administrator access to.

For customer self-service, the most commonly used web role for table permissions tends to be Authenticated Users, meaning that only logged in portal users receive this permission. 

If, for example, your portal has an enquiry form allowing the public to submit leads without the pre-requisites of registering for and logging into the portal, you would add the Anonymous Users web role to the table permissions for the Lead table.

In addition to these out-of-the-box web roles, we can create any number of custom web roles to provide more granular security trimming.

Examples of ‘personas’ that might require different levels of access (web roles)

Here are some more examples of where it might make sense to create additional / custom web roles for your portal project. Think of how the required level of access and level of visibility within the same web app would differ between the following personas:

Education

Teacher vs Student vs Parent

Property

Landlord vs Tennant vs Guarantor vs Solicitor

Spotify

Free Listeners vs Premium Subscribers vs Record Label Staff vs Independent Artists

Tiered access

Membership tiers / support plans e.g. Gold support plan vs Silver support plan vs Free

Further reading – the sequel

Interested in learning more? Would you like to see some examples to help consolidate your learning? Check out part 2 where I break down the table permissions that come out-of-the-box with the Customer Self-Service starter portal