2
votes

More specifically: I have small Azure AD under which i have registered my application. The application is marked as multi-tenant as i want people to be able to log in to it with their own corporate accounts. I would like to obtain the group memberships for the users that login by leveraging delegated access rights that do not require admin consent because I don't want the on-boarding process of new AAD tenants to require an admin over there to grant my app special permissions.

Here is what i have tried:

Getting the information directly in the tokens

By configuring the groupMembershipClaims field in my application manifest to All as documented here. I can obtain the groups in my token. This can be done without any sort of admin consent. in fact the only delegated rights needed are openid ie logging the user in.

This approach however limits me to obtaining the groups for users who are members of less than 200 groups. Otherwise I get none at all and instead get an endpoint to the Azure Graph API where I can retrieve them.

This leads us to the second approach.

Using Microsoft Graph API

Sadly both the old Azure Graph API and the new Microsoft Graph API Seem to require permissions with admin consent to get the groups.

The documentation for the user: getMemberGroups call states that we should be able with a delegated User.Read permission to make this call. However this does not work and in fact Directory.Read.All is the least permissive permission that actually works. See the documentation issue on GitHub.

Looking at the documentation's history we can see that this used to be considered a known bug rather than a documentation problem. Going back further seems to imply that at a minimum both User.Read and Group.Read.All together were required.

This leaves me kind of stuck. Ideally would prefer to use the graph api in all cases rather than just the over 200 case because otherwise my tokens can get too large for some uscases despite the limit microsoft put in. But I'm not sure what the actual intent is here with regards to needing admin consent for this sort of query.

Does anyone have any other ideas?

1
The user you use in your app will need to read the entire directory to verify users are in it. That’s how the old school AD and LDAP works. Even if features were disabled, as an authenticated user you can most often spin up PowerShell or Javascript and see all the users. - user9105725

1 Answers

1
votes

There is no way currently (2019-03-20) to get group membership information for the signed-in user without an Azure AD directory admin consenting to the delegated permission Directory.Read.All. (There are plans to support a lesser-privileged permission for this scenario, though it may still require admin consent by default.)

You should not build your application with the assumption that all users will be able to use your app because you're only requesting permissions that are currently user-consentable by default. Many organizations disable user consent entirely, and you can expect that in the future which users can consent to which permissions will be something that changes for each organization.

My recommendation is the following:

  1. Before sending the user off to sign in, clarify that their organization's policy may not allow them to sign in (and suggest they reach out to their IT team if that's the case). (In the future, there will be more options for users faced with the "sorry, you're not allowed to consent" error...)
  2. Consider starting with only requesting User.Read (and groups claim), and only "stepping up" to Directory.Read.All later in the app's experience. This will increase the probability (though does not guarantee) that the user will be able to at least sign in, and may allow you to offer them better guidance for how to ask their IT team to review your app.

There is some additional guidance at: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#using-the-admin-consent-endpoint