Power Platform authorization
Since companies are becoming more and more data driven, one of the main requirements for business-critical applications is comprehensive authorization. As a low/no code development platform operating in the “last mile” of business application space, it is vital to understand all the extensive features the Power Platform brings in relation to this topic.
In the process of gaining an understanding of this myself, I have documented the information in a few diagrams which, with some textual support, end up giving a nice overview of the possibilities you have, to tailor the authorization model to specific business needs.
Why?
The authorization features allow control over the accessibility to resources within the Power Platform while minimizing maintenance, being able to fulfil needs like:
- A new employee must have direct access to environment X but not to environment Y.
- Employees can only edit their own worklogs.
- Sales managers should have access to all the leads owner by the Sales employees they manage.
- A warehouse employee should only be able to edit the dimensions of a product.
Even though all this information can be found in the extensive documentation and learning paths, I found it valuable to collect it in one article so I could order in a way it makes sense to me in my brain. Since I work primarily in Power Platform environment with a Dataverse database in place, this has been my paradigm for the overview as well, although I try to also mention differences with non-database environment when they are relevant.
What?
To control authorization, the Power Platform depends on several entities of which each corresponds to a different level of granularity.
Let us check these out and see how they are interrelated.
Business Units
- These are the main entity to classify users and teams.
- They exist in a tree structure where there is always one root.
- Every user exists in 1 business unit.
- Business units allow an administrator to authorize specific resources/tables in such a way that these are accessible to only users in the same business unit or allow access to all resources which are owned by users/teams in a child business unit.
- Note that having a lot of business units impact performance of apps quite a bit. Take this into account when designing your authorization model.
- Although it might be tempting to mimic the organization chart, only do this when there is an actual security requirement to do so. Just in time, just enough.
Teams
- Owner team: The primary team of a user.
- Access team: These are extra teams which provide access to resources for users outside of the business unit to which they belong.
- Each business unit has one owner team and zero or more access teams.
- Azure Directory Group Team: Comparable to an owner team and can be utilized when an environment has a Dataverse database. These can be used to apply authorization from the context of AD and lightens authorization maintenance. Adding for example a new employee to a group team that has access to an environment automatically grants the employee access as well.
- Working with teams allows you to mitigate authorization maintenance overhead.
Users
- Users are created in the Azure AD tenant and login with their Office 365 accounts.
- A User is always in one business unit.
- Is always in one owner team.
- Can be in zero or more access teams.
- Users become Power Platform users when they have a license and:
- Always have access to the Default environment(!)
- Have access to environments without database.
- Have access to environments with database if connected to the authorized AD Group Security.
- Receive access based on security roles connected to the corresponding team or the user itself.
Security Roles
- Contain authorization settings within a certain environment.
- Environments without database have two:
- Environment Admin
- Environment Maker - Environments with a database have 9 standard roles and allow for custom roles.
- These are connected to zero or more users or teams.
- Multiple roles can be active on the same user/team. This allows for efficient “stacking” of authorization.
- Roles determine access to specific actions (i.e., Export to Excel)
- Roles determine access to CRUD+ (Create Read Update Delete Assign etc.) actions on table rows.
How?
To understand how these different authorizations effectively work we can observe the diagrams below, starting with the highest level of abstraction, Environment level.
Environment Security
This level depends on the fundamentals of Azure Active Directory tenants, combining licenses and security groups depending on the environment type.
Resource Security
Resource authorization is managed primarily through security roles, and for field level security the field security profiles can be utilized.
Table row security
Table row authorization is managed primarily through security roles. Note that tables can also be created with Organizational security. In these cases, you cannot control row access on a team/user level. Because of this, it is good practice that when in doubt, always configure tables with team/user security.
Per table you can control authorization on the following action:
- Create
- Read
- Write
- Append
- Append to
- Assign
- Share
Per action you can state the following scope:
- None
- User
- Business Unit
- Child Business Units
- Organization
For example: For the Security role “Team lead”, on the table “Inspections” the action Delete is set to scope “Business Unit”. This means that a user with the security role “team lead” can delete all inspection rows where the owner is in their business unit.
Table column security
If row level security is not granular enough, it is possible to go one step beyond and authorize on column level. For this you can create field security profiles and connect them to specific teams or users. Per column you can define whether or not a user can:
- Read
- Update
- Create
Note that this is not controlled by security roles, and increase maintenance overhead considerably.
Hierarchical security
Power Platform also allows for hierarchical authorization models, which are less straining on performance than large numbers of business units but allow for complex and highly granular authorization structures. These exist in two categories:
- Manager hierarchy:
- Uses the “manager” field on the systemuser table from Azure AD to determine the hierarchy.
- Makes it impossible to gain access outside the boundaries of the users own business unit. - Positional hierarchy:
- Complete freedom to set up in terms of hierarchy as it does not depend on any systemuser table value.
I have not yet had the need to work with these models, but I will elaborate on these once I gain more field experience with them.
Power platform security tips and best practice
- Do not use the default environment for production or actual business critical scenarios, as everyone in the tenant will have access to it. It is best to rename it to Personal development or something similar to indicate this.
- Limit the use of business units. This prevents performance and maintenance issues later.
- Create a user role which contains the authorization for most of the users (Baseline) and then create and stack separate roles for specific (groups of) users on top. This prevents having to apply changes to the model over all security roles.
- For maximum freedom and efficiency, it is advised to combine the baseline/stack strategy with positional hierarchy. However, this will completely depend on your use case.
Concluding
The extensive authorization options the Power Platform offers are powerful and can fulfil pretty much every requirement you can expect in the field. However, this power comes with the responsibility of truly understanding the impact of your initial implementation and changes you make later. I hope this overview helped with this.
