Minimum privileges in model-driven PowerApps
When you’re building an app in the Common Data Service for Apps, how do you keep it secure?
I was digging around for answers to a customer question on the docs.com site when I ran across something that made me stop in my tracks. If you’re planning on making a model-driven PowerApp, you should pay attention.
Microsoft offers a minimum privilege security role that you can import to your environment and build upon for your app.
You might be wondering: Why should I leverage this when making an app?
Keep your app secure
PowerApps harness the world-class identity management and security provided through Azure & Office 365, while offering it though an easy to configure and deploy interface for your own app. If you’re an app maker, you don’t need to understand the mechanics of managing database security, tracking activity, and offering single-sign-on to users. The PowerApps platform, backed by the Common Data Service for Apps takes care of the heavy lifting for you.
The part you’re responsible for is to set up security definitions based on what you want your app to do. This is where the minimum privilege security role makes life easy. It’s a starting point with all of the basic level permissions that let a user log into an app, navigate, and use core actions and capabilities that are shared across apps.
From there, you add incremental privileges to a copy of that. For instance, a standard user may only be able to see and modify their own records, while a manager may be able to see and modify the records of everyone on the team.
Make your app more modular
Previous methods have existed to do this same thing, the most common two being:
- Copy one of the out-of-the-box roles, like Salesperson, then strip away the Sales stuff
- Assume users will have another security role with the minimum privileges
The first one is the approach I’ve preferred in the past, but it takes extra work to make sure you remove every little dependency to the Sales app. Suppose you want to deploy to an environment where Sales isn’t deployed.
The second app is less and less viable as the Common Data Service and PowerApps platform stand more on their own, separate from the 1st party apps. Frankly, unless a user is going to leverage capabilities that are part of the 1st party apps it’s tough to assume users will be assigned one of the out of the box security roles. Are you willing to make that assumption?
Make your app easier to deploy
I was having a discussion with a colleague about a community project we’re working on to build out some capabilities to extend the Health Accelerator. He was asking why we’d include security roles with our solution, since customers can tailor security for their deployment anyway.
The discussion we got into was on driving a quicker and easier deployment of the solution. Sure, an administrator (or partner) could analyze the specific needs for their deployment and tailor roles…in fact, they still can. But what about the customer that wants to install and get going right away?
By having these predefined security roles, customers can install and test the solution with minimal up-front work–without impacting their ability to tailor later. These predefined roles also serve as a template for basic user types (like those of the Dynamics 365 1st party apps like Sales, Service, etc.).
Take action!
If you’ve read this far, it’s time to get hands-on.
- Read more about PowerApp security roles
- Download your copy of the minimum privileges security role
- Let me know what other little goodies like this are out on docs.com!
