Understanding the new Granular Permissions for App Access to Teams data
Microsoft announced in the message center this week that resource-specific content will roll-out to tenants, beginning mid-August. This opens the door for installing richer applications than you would have previously considered approving and allows self-service installation by Team owners.
Teams applications based on the Graph API to read and write content within a Team, such as full team membership, channel structure, chats and files, were often difficult to deploy. This is because an application was not able to limit its request to access data for only that specific team.
Instead, an administrator needed to grant access to the application for all Microsoft 365 Groups data, creating both a potential security risk and work for administrators who processed access requests for routine application access by users.
This would mean that if a user wanted to add a Team-specific application, such as one that provided specific capabilities only applicable to their team, the administrator would need to grant access to that application at a tenant-level, providing access to all messages, channels, membership list, files, calendar, and plans.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
The resource-specific content model is the solution to this problem and provides the opportunity for Teams application developers to design applications that can request specific permissions related to the resource, such as a particular Team, that they are trying to access.
Applications designed to take advantage of this model request permissions when they are added to the Team itself, as part of the normal installation process by a Team owner:
Application developers can now create applications with granular permissions, including the ability to be read-only for settings, channels, or messages; or have specific create, update and delete abilities, such as the ability to edit the Team’s settings, configure tabs, manage memberships and manage channels.
This potentially opens additional concerns regarding the type of applications that users may choose to install, especially if the applications have not been pre-approved by the business before end-users install them.
Additionally, even for previously trusted applications, the storage of data in their services – outside of the boundaries of Microsoft 365, may be undesirable.
The defaults for resource-specific consent are designed to follow existing settings you may have configured for Azure AD. Therefore, if you already allow a user to provide consent to applications accessing company data, then this new capability will be enabled by default.
If you are following what many other organizations are doing and preventing users from consenting to applications at a user level, the good news is that resource-specific consent will be disabled by default.
These Azure AD level settings are found in the Azure AD Portal, within Enterprise applications, under user consent settings. The defaults are shown below:
The specific settings that affect Teams resource-specific consent are the group owner consent for apps accessing data.
You can update these new settings in advance of resource-specific consent roll-out to either:
- Do not allow group owner consent
- Allow group owner consent for selected group owners
- Or leave the default – allow group owner consent for all group owners.
Given the impact of allowing users to provide consent to potentially any application, it is worth considering whether you wish the default to remain as-is, and instead consider whether it’s worth limiting this capability to a particular set of group owners.
Additionally, if you do plan to allow consent to be given, ensure you take time to review the Teams applications available to the organization in the Teams Admin Center. You can block applications that do not meet your security policies, and ensure new applications are not automatically approved at an organization level within the Manage Apps section:
If there are applications that only certain groups of users within your organization need access to, you can then restrict applications using App Permission Policies. These will allow you to create policies only allowing approved applications for user access.
By combining the ability to review at an organization-level the applications that are safe, then restrict by a particular team the allowed applications – and ensure that only specific users can consent to allowing safe applications resource-specific consent, you can make sure that your users can take advantage of these great new capabilities for Teams applications safely.