There have been some changes to terminology since I first wrote this:
- Entity Permissions are now known as Table Permissions and entities are now known as tables
- Scope is now known as Access Type
Note – depending on when you last updated your portal solutions, yours may still use the old terminology
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 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:
- Append To
Note – I go into these in more detail shortly, right after ‘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
|Global||Allows all portal users to see / interact with all records, no relationship required, no security trimming applied||Allow everyone to see and select all the products you offer / the full list of subjects|
|Contact||Allow portal users to see / interact with records that they have a direct relationship with||Personal bank accounts where they (the contact) are the customer / account holder|
|Account||Allow portal users to see / interact with records that their account has a direct relationship with||Invoices where the portal user (contact)’s parent account is the customer|
|Parent||Allow portal users to see / interact with child records associated with a record with which they (the contact) or their account has a direct relationship with||Attachments regarding a bank account where either:
a. the portal user (contact) is the customer / account holder
b. the portal user’s account is the customer / account holder
|Self||Allow the portal users to see / interact with their own contact record||Logged in portal users (contacts) are able to amend their contact information and preferences on the Profile page in the portal|
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?
|Read||See existing records||View a list of cases|
|Write||Edit existing records||Update an existing case|
|Create||Create new records||Raise a new case|
|Delete||Delete existing records||Delete portal comments|
|Append||Relate records for this table to other records||Attaching a document to an application form (The Append privilege is required on the table that the portal user is attaching ‘from’ i.e. the document)|
|Append To||Relate records to this table||Attaching a document to an application form (The Append To privilege is required on the table that the portal user is attaching ‘to’ i.e. the application)|
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
- 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?…
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:
Teacher vs Student vs Parent
Landlord vs Tennant vs Guarantor vs Solicitor
Free Listeners vs Premium Subscribers vs Record Label Staff vs Independent Artists
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