您可能在这里混淆了两个完全不同的概念。我将在下面提供有关每一项的一些详细信息,然后您可以决定是否真的需要为您的申请提供团体索赔。
我的猜测是您对角色声明感兴趣,因此您无需更新应用清单以包含 "groupMembershipClaims": "SecurityGroup",但您是应用程序要求的最佳判断者。
应用程序角色
您可以通过编辑应用清单并添加 appRoles 来定义应用角色。现在,您可以将这些角色分配给单个用户,甚至分配给 Azure AD 组。
-
为个人用户分配角色
您可以通过转到企业应用程序然后使用门户 UI 将角色分配给各个用户。看起来您已经为您的应用完成了这项工作。当用户登录到您的应用程序时,传入的访问令牌包含用户的角色声明。例如"roles": ["MyAppCustomRole1"]
-
为 Azure AD 组分配角色
您可以将应用程序角色分配给 Azure AD 组(如果您有 Azure AD Premium)。这很方便,尤其是在处理大量用户时。这样,您无需将 appRole 分配给单个用户,而是可以根据他们的组成员身份进行批量分配。
如果这是您要执行的操作,则无需更新应用清单以包含 "groupMembershipClaims": "SecurityGroup"
示例代码 - Authorization in a web app using Azure AD application roles & role claims
微软文档 - Application roles
团体声明
您可以通过编辑应用程序的清单(这可以直接在 Azure 门户中完成)并将"groupMembershipClaims" 属性设置为"All" 或"SecurityGroup" 来启用组声明作为应用程序访问令牌的一部分需要。
如前所述更新应用程序清单后,您可以获取组 ID 作为声明的一部分。这是解码的 JWT 令牌的快速示例。请注意,与前面解释的角色声明相比,这是一个完全不同的声明。
示例代码 - Authorization in a web app using Azure AD groups & group claims
组与角色
请了解 Azure AD 组及其成员资格与任何单个应用程序完全分开。
Azure AD 组的生命周期也可能不同,即一个组可能会在应用程序被删除或不再需要后继续存在很长时间。
另一方面,应用程序角色与一个特定应用程序密切相关。
对于某些应用程序,授权策略是检查用户的组成员身份,而不是特定于应用程序的角色。我还看到应用程序根据应用程序特定角色和用户所属组的组合做出授权决策的案例。
附带说明,为确保令牌大小不超过 HTTP 标头大小限制,Azure AD 限制了它包含在组声明中的 objectId 的数量。如果用户是超过超额限制的组的成员(SAML 令牌为 150 个,JWT 令牌为 200 个),则 Azure AD 不会在令牌中发出组声明。相反,它在令牌中包含一个超额声明,指示应用程序查询 Graph API 以检索用户的组成员资格。
其他相关的 SO 帖子: