This Kiefer technical blog outlines best practices and will demonstrate how to configure security and permissions for a Microsoft PowerApp.
As a technologist, you’re probably always looking out for the next killer app. That app that transforms your processes or gives your organization a competitive edge. If you have an idea of what that might look like, stop wishing for it to appear and make it happen with Microsoft PowerApps. PowerApps is a low-code application that lets you build and launch apps on a mobile or desktop interface using pre-built templates, drag-and-drop simplicity, and quick deployment. Whether you’re looking to build something transformative or simply an interface used to consume and modify data, PowerApps is designed for both IT experts and novices.
When you’re investing time and resources in building the next killer app, you want to make certain it’s secure. So in this Kiefer Deep Dive, we’re looking at PowerApps security and permissions. Ideally, when building an app in PowerApps, you’ll want to build security into the development stages. While there are various avenues to approach this, Kiefer’s best security practice is to leverage Azure Active Directory into the PowerApps application. Additionally, we’ll be quickly covering the following topics:
- PowerApps Permissions
- PowerApps provides two methods of security layers:
- App Sharing
When you’re building a PowerApp meant to be available to your entire organization, you will need to at some point, obviously, share the PowerApp with the entire organization. This is a necessary step if you intended for members your organization to use the PowerApp. This is important because it facilitates visibility and helps yield a granular approach to security by using group membership rather than individual users. To share, simply add “Everyone” to the list of users to ensure everyone in the organization can access the application.
Azure Active Directory Groups
Azure Active Directory is beneficial because it provides a secure, separate area to manage user membership within security groups. Each security group has a unique Object ID. This allows a single source of truth, meaning Azure Active Directory is the “go-to” platform where users are added or removed from security groups. Depending on their security group, one can enable or disable specific functionalities within the PowerApp. In this example, security groups have been created within the Azure Active Directory admin center. Simply add and remove members to each group as needed.
Before security through visibility can be implemented, set PowerApps to retrieve a list of users from the Azure Active Directory Security Groups. To retrieve a list of users from the Azure Active Directory Security Groups, you’ll need to utilize the AzureAD Data Connection available within PowerApps.
Fair warning – at this point the “deep dive” part of this post starts to really kick in. If you’re a no- or low-code user, you’ll be forgiven for abandoning ship here.
In PowerApps, galleries serve as “a control that contains other controls and shows a set of data. A Gallery control can show multiple records from a data source, and each record can contain multiple types of data,” per Microsoft. In this example, we’re going to open a hidden screen and add a gallery to the page. In this example, we have two galleries:
For each gallery, the Items property returns a list of up to 500 members from the specified group. The formula is as follows:
Items = AzureAD.GetGroupMembers(“GroupID“).value
Items = AzureAD.GetGroupMembers(“1cbb729d-544a-468d-ad8f-8a02c2903b5f”).value
Formula Visible Property
By default, every object within a screen has a “Visible” property set to “true”.
Now we can change this Visible property to only be true when the user is a member of an AD Security Group using this formula:
Visible = User().Email in Gallery.AllItems.userPrincipalName
Visible = User().Email in ADGroupAdmins.AllItems.userPrincipalName
User.Email() will always be equal to the User Principal Name (email@example.com) of the logged in user.
The Gallery we are referencing in the example is the name of the gallery that retrieves the members from our “AssetDemo-Admins” Azure Active Directory Security Group.
For example purposes, we replicate this process for the “Visitors” button. The current user who is logged into PowerApps cannot view the button because they are not a member of the “AssetDemo-Visitors” Azure Active Directory Security Group. Since the current user’s User Principal Name does not match with an item within the “ADGroupVisitors” gallery, the button is not visible.
The point of this example was to illustrate how a hidden screen containing a gallery of users from an Azure Active Directory Group allows app builders to reference this gallery for visibility purposes. This is the best way to tailor the user experience for users within the PowerApp based on their group membership.
We hope you found this deep dive into PowerApps security and permissions valuable. We’ll be taking some more deep dives into Microsoft tools in the future. If you have ideas for topics you’d like our experts to blog about, let us know by emailing us at firstname.lastname@example.org