【问题标题】:Get a list of groups that Azure AD user belongs to in claims在声明中获取 Azure AD 用户所属的组列表
【发布时间】:2018-06-13 19:46:29
【问题描述】:

我正在针对 Azure Active Directory 对我的 Web api 的用户进行身份验证。 现在我想获取该用户所属的组列表。

我更改了应用程序清单以包含

"groupMembershipClaims": "All",

但这所做的只是添加声明 hasGroups 但没有组名。

我在门户中为我的应用授予了 Windows Azure Active Directory 的所有 (8) 项委派权限。

【问题讨论】:

  • 当用户属于超过 5 个组时,会添加“hasGroups”声明,即使这似乎没有在任何地方记录。 5 个或更少,您会收到一些带有组对象 ID 的“组”声明。

标签: .net azure-active-directory adal azure-ad-graph-api


【解决方案1】:

我确实做到了。

让我们将我的 Azure AD 应用程序称为“AD-App”。

广告应用

其他应用程序的权限设置为;

Windows Azure 活动目录。

应用程序权限:0。

委派权限 2(“读取目录数据”、“登录并读取用户配置文件”。

Manifest 有如下设置:

"groupMembershipClaims": "SecurityGroup"

后端 API

以下是我返回用户组的方法。要么您发送用户 ID,否则它使用声明中的 ID。 Id 的意思是“objectIdentifier”。

        public static IEnumerable<string> GetGroupMembershipsByObjectId(string id = null)
    {
        if (string.IsNullOrEmpty(id))
            id = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;

        IList<string> groupMembership = new List<string>();
        try
        {
            ActiveDirectoryClient activeDirectoryClient = ActiveDirectoryClient;
            IUser user = activeDirectoryClient.Users.Where(u => u.ObjectId == id).ExecuteSingleAsync().Result;
            var userFetcher = (IUserFetcher)user;

            IPagedCollection<IDirectoryObject> pagedCollection = userFetcher.MemberOf.ExecuteAsync().Result;
            do
            {
                List<IDirectoryObject> directoryObjects = pagedCollection.CurrentPage.ToList();
                foreach (IDirectoryObject directoryObject in directoryObjects)
                {
                    if (directoryObject is Group)
                    {
                        var group = directoryObject as Group;
                        groupMembership.Add(group.DisplayName);
                    }
                }
                pagedCollection = pagedCollection.GetNextPageAsync().Result;
            } while (pagedCollection != null);

        }
        catch (Exception e)
        {
            ExceptionHandler.HandleException(e);
            throw e;
        }

        return groupMembership;
    }

我不能告诉你这是否是最佳实践,但它对我有用。

【讨论】:

  • 对任何读者的重要说明:编写的后端 API 方法不会检索传递组成员资格。前一种方法是通过 AD 门户配置。
  • 感谢为我工作 :-)
  • 如果你在上面的例子中包含了必要的命名空间,那就太好了。
  • @Rod - 天哪,这是很久以前的事了,我不能确定!但是,我确实相信当时它是一个作为 Azure Web 应用程序运行的 WebAPI 项目 :) 希望它有所帮助!
  • ActiveDirectoryClient activeDirectoryClient = ActiveDirectoryClient 这行不行。
【解决方案2】:

这是我们在一个项目中所做的:

登录https://portal.azure.com 并点击Azure Active Directory -> App registrations -> &lt;YOUR_APP&gt; -> Manifest 并将groupMembershipClaims 设置为7。您可以在此处阅读更多相关信息:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-manifest

然后您可以像这样访问用户组:

[Route("api/[controller]")]
[ApiController]
public class CurrentUserController : ControllerBase
{
    [HttpGet("groups")]
    [ProducesResponseType(typeof(IEnumerable<ClaimsViewModel>), (int)HttpStatusCode.OK)]
    public IActionResult Groups()
    {
        return Ok(User.Claims.Where(claim => claim.Type == "groups").Select(c => new ClaimsViewModel() { Type = c.Type, Value = c.Value }));
    }
}

public class ClaimsViewModel
{
    public string Type { get; set; }
    public string Value { get; set; }
}

使用虚假对象 ID 的示例响应:

[{"type":"groups","value":"12fef9e0-4b73-425d-91b7-30c027aa4945"},{"type":"groups","value":"12fef9e0-4b73-425d-91b7-30c027aa4946"},{"type":"groups","value":"12fef9e0-4b73-425d-91b7-30c027aa4947"},{"type":"groups","value":"12fef9e0-4b73-425d-91b7-30c027aa4948"},{"type":"groups","value":"12fef9e0-4b73-425d-91b7-30c027aa4949"}]

有了这些 ID,您就可以识别 AD 中的组。

【讨论】:

  • 这里有一个大警告:如果用户在超过 5 个组中,他们只会得到 OP 提到的“限制令牌大小”的“hasGroups”声明。意外地遇到了这个。
【解决方案3】:

如果用户拥有超过 150 个组,则仅返回指向“graph:link”等 calim 中的 Graph API 的链接,而不返回组。这样做是出于性能原因。然后,您需要调用 Graph API(MS Graph API - 最新,或 AD Graph API - 较旧)来迭代所有组。

【讨论】:

    【解决方案4】:

    您为您的应用授予了哪些权限?您需要明确请求读取组的能力(请参阅https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes 中的 group.read.all)。截至今天,这些权限只能由管理员同意。

    【讨论】:

    • 我添加了有关添加权限的信息
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-29
    • 2020-02-28
    • 1970-01-01
    • 2012-07-22
    • 1970-01-01
    相关资源
    最近更新 更多