We have had several requests to restrict the access alllowed by the Azure AD User.ReadAll Application API permission. Our application only needs access to a couple of the fields in the User object and our customers, for security reasons, would prefer not to allow us access to every possible property. Allowing the Azure portal to specifically list attributes per object that are exposed to a given API Registration would address this security need.
e.g. API Registration ABC for User.ReadAll Application permission would be given access only to the ID, Mail, and DisplayName properties.
2 Comments
- lindalu-MSFT
Microsoft
Hi, we apologize for the confusion where to post your Graph feedback. This community was intended to be a temporary location for developers to submit product feature suggestions between Microsoft moving off of UserVoice and the release of Microsoft's official Feedback portal app. Now that the latter is released, we encourage you to resubmit this great suggestion on the official Microsoft Graph Feedback portal at Microsoft Graph · Community.
Kind regards,
Linda
Microsoft 365 Developer Platform community steward
First of all i agree on the need for more granularity on Graph Api Permissions.
For example: more and more suppliers of SaaS business application are integrating on AzureAD for SSO and syncing of some user details. Therefore they need an "App registration" with necessary permissions. In much cases there is only need for user attributes as first name, surename and emailaddress.
Besides this there is only need to read a selection of users for a specific business application. To organize this now, you need "GroupMember.Read.All" and "User.Read.All". This is to broad.
The business application can read All Members of All groups and can read All users with all attributes. Undesirable
What we want is: permissions to read members (users) of specified (single) group(s) ... for selected member (user) attributes.
Context: we have 42 organisational units with different kind of work and legal frameworks. And +- 400 business applications in transition to SaaS. On top of this: a shared service center is providing the tenant as part of a regional cooperation of multiple organisations. The permission "User.Read.All" gives also the possibility to read users from other organisations.
Without extra granularity or an other solution we can't work fully work GRPD compliant.
ps. working in a single tenant/ directory for our situation, is the prescribed recommendation from Microsoft.
