如何获取当前登录用户的Azure AD组而无需域管理员向我的应用程序授予任何权限? [英] How do I obtain the Azure AD groups of the currently logged on user without needing a domain admin to grant my application any rights?

问题描述

更具体地:我有一个小的Azure AD，在其下注册了我的应用程序.该应用程序被标记为多租户，因为我希望人们能够使用自己的公司帐户登录到该应用程序.我想利用不需要管理员同意的委派访问权限来获取登录用户的组成员身份，因为我不希望新AAD租户的入职过程要求那里的管理员授予我的应用特殊权限权限.

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.

这是我尝试过的:

通过将我的应用程序清单中的groupMembershipClaims字段配置为All，如此处.我可以用令牌获取组.无需任何管理员同意即可完成此操作.实际上，唯一需要的委派权限是openid，即登录用户.

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.

但是，这种方法限制了我为少于200个组的成员的用户获取组.否则，我什么也得不到，而是获得了一个Azure Graph API的终结点，可以在其中检索它们.

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.

同时使用 old "> 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.

用户的文档:getMemberGroups 调用指出，我们应该能够具有委派User.Read的权限才能进行此调用.但是，这不起作用，实际上Directory.Read.All是实际起作用的最小许可权限.请参阅GitHub上的文档问题.

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.

查看文档的历史记录，我们可以发现它曾经被视为已知错误，而不是文档问题.再往前看似乎暗示至少同时需要User.Read和Group.Read.All.

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.

这让我有些困惑.理想情况下，宁愿在所有情况下都使用图API，而不是仅在200种以上的情况下使用图api，因为否则，尽管Microsoft设置了限制，但在某些情况下，我的令牌可能会变得太大.但是我不确定这方面的实际意图是什么这种查询需要管理员同意.

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.

还有其他想法吗?

推荐答案

在没有Azure AD目录管理员同意委派的情况下，当前无法(2019-03-20)获取登录用户的组成员身份信息.权限 Directory.Read.All . (虽然在默认情况下可能仍需要管理员同意，但仍计划为此情况提供较少特权的许可.)

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.

我的建议如下:

1. 在将用户送出登录之前，请澄清其组织的政策可能不允许他们登录(并建议联系他们的IT团队). (将来，面对对不起，您不能同意"错误的用户，还会有更多选择.)
2. 考虑从 only 开始请求 User.Read (并要求团体声明)，并且仅逐步"升级到 Directory.Read.All 该应用的后续经验.这将增加(至少不能保证)用户至少能够登录的可能性，并且可能使您可以为他们提供更好的指导，以要求他们的IT团队审阅您的应用程序.

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

这篇关于如何获取当前登录用户的Azure AD组而无需域管理员向我的应用程序授予任何权限?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！