我正在创建一个使用Azure AD用户组向特定资源授予权限的应用程序。例如，一组特定的文档只能由特定组中的用户访问。该应用程序在JWT上接收组ID作为声明，并确保只有在声明中分配给组的文档才可见。
现在，问题是如何在Azure AD中正确管理组。将用户分配到某个组后，将成为该组的成员，并且该组将嵌套在该组中。这似乎意味着我的组嵌套应该与我想要的树结构相反。像这样：
管理员->->组成员的访问权限最大->->组成员的访问权限较少->->组成员的访问权限最少。
在我看来，这是倒退，但它为添加到每个组的用户提供了正确的访问权限。
我是要离开这里吗，还是这是管理AD组访问权限的合理方法？
答案 0 :(得分：0)
在AAD中，组中成员的权限取决于其所属组中最大的权限。例如，A组可以访问资源而B组无法访问资源，该人同时在A组和B组中，那么他将能够访问该资源。
在我看来，这是倒退，但它为添加到每个组的用户提供了正确的访问权限。
让我们将这三个组称为A，B，C，它们的许可为A> B> C。显然，如果将A添加到B，则A和B的权限都不会受到影响。但是，如果将B添加到A，则A或B中的成员都将拥有最大的权限，这不是您想要的。与B和C相同。这就是为什么它为您添加到每个组的用户提供正确的访问权限。
因此，我个人认为，似乎无需使用嵌套组，只需使用三个具有不同权限的组就足够了。
答案 1 :(得分：0)
@JoyWang已经在上面的回答中涵盖了一些优点。以下是一些其他注意事项。 免责声明：由于问题的性质，我在这里的回答主要是观点和一些案例的学习。想法是分享我如何看待群组以及一些相关信息。
这些组是特定于您的应用还是更具通用性？组成员身份和嵌套组通常用于逻辑/直观地组织用户和组，而不是针对特定应用程序设计权限
很多时候，一个以上的应用程序使用Azure AD组，并且其寿命可能会比您正在开发的任何一个特定应用程序更长。
您在考虑嵌套组的方式（基于哪个组具有更多的访问权限而较少的访问权限），您可能只关心正在开发的一个特定应用程序，并考虑了组对此应用程序的访问权限。如果您计划创建的组也非常特定于应用程序，并且不会用于任何其他目的，则可以采用这种方法。
示例1：您的应用程序是博客应用程序，您在Azure AD中创建的组是Viewer，Contributor和Admin。 （管理员>贡献者>查看者） 示例2：您有一家使用Azure AD的企业，并且各组按逻辑组织用户，例如进行明智的市场营销，人力资源，工程等。
因此，您根据访问权限从低到高的顺序来描述嵌套的组，从技术上讲，它适用于像Example1这样的更简单的方案，但不适用于Example2中的更通用的组。
很多时候，通用组已经存在，您应该重用它们，而不是为您的应用程序创建新的通用组，而这些又需要新的分配/成员资格，但这可能会或可能不适用于您的特定情况。< / p>
此外，可以有多个人来管理这些组及其成员，因此即使您有时不得不牺牲一些特定于应用程序的效率，您提出的任何设计/组织模式都应该重视直观性。
我认为，您可以查看平面组或嵌套组。.从用户和组的角度来看，这是否有意义，而不仅仅是访问权限。另一个虚构的示例：Marketing组可以有一个像Marketing Content Approvers这样的成员组，因为它是市场营销人员的子集。
请考虑使用Application Roles。
它们特定于应用程序，与应用程序的清单相关联，可以作为令牌中声明的一部分供您使用。
在某些情况下，例如基于单个资源的访问，您想授予对特定资源的权限，在这种情况下，应用程序角色可能有意义，也可能没有意义，并且您仍然需要直接依赖组或用户。无论如何，这是您可以使用的另一个有用的选项。
管理组（如您在评论中所问的那样）
查看Self Service Group Management Scenarios（委派的v / s自助服务），以及Dynamic Groups中基于属性的动态成员身份规则（尽管需要高级许可证）。