适当使用Azure广告组来管理权限

我正在创建一个使用Azure AD用户组向特定资源授予权限的应用程序。例如，特定的文档集只能由特定组中的用户访问。应用程序将组ID作为JWT上的声明接收，并确保仅分配给声明中的组的文档可见

现在，问题是如何在Azure AD中正确管理组。当用户被分配到某个组时，该组将成为该组的成员，并且该组嵌套在其中的任何组中。这似乎意味着我的组嵌套应该与我想要的树结构相反。大概是这样的：

管理-->访问权限最多的-->组成员-->访问权限较少的-->组成员-->访问权限最少的-->组成员

对我来说，这似乎是倒退，但它为添加到每个组的用户提供了正确的访问权限

---

我在这里是否偏离了底线，或者这是管理广告组访问权限的合理方式？

在AAD中，组中成员的权限取决于他所属组的最大权限。例如，A组可以访问一个资源，B组不能访问它，这个人同时在A组和B组，那么他将能够访问该资源

对我来说，这似乎是倒退，但它为添加到每个组的用户提供了正确的访问权限

让我们将这三个组称为A、B、C，它们的权限是A>B>C。显然，如果将A添加到B，A和B的权限都不会受到影响。但是如果你将B添加到A中，A或B中的成员都将拥有最大的权限，这不是你想要的。B和C也是如此。这就是为什么它为添加到每个组的用户提供正确的访问权限的原因，正如您所说的

---

因此，在我个人看来，似乎没有必要使用嵌套组，只要使用三个具有不同权限的组就足够了。

在AAD中，组中成员的权限取决于他所属组的最大权限。例如，A组可以访问一个资源，B组不能访问它，这个人同时在A组和B组，那么他将能够访问该资源

对我来说，这似乎是倒退，但它为添加到每个组的用户提供了正确的访问权限

让我们将这三个组称为A、B、C，它们的权限是A>B>C。显然，如果将A添加到B，A和B的权限都不会受到影响。但是如果你将B添加到A中，A或B中的成员都将拥有最大的权限，这不是你想要的。B和C也是如此。这就是为什么它为添加到每个组的用户提供正确的访问权限的原因，正如您所说的

---

所以在我个人看来，似乎没有必要使用嵌套组，只要使用三个具有不同权限的组就足够了。

@JoyWang已经在上面的回答中提到了一些好的方面。这里有一些额外的考虑。免责声明：由于问题的性质，我在这里的回答主要是观点和从一些案例中学习。我的想法是分享我是如何看到一些相关的信息一起使用团体的

这些组是针对您的应用程序的还是更通用的？组成员资格和嵌套组通常用于逻辑/直观地组织用户和组，而不是特定应用程序的设计权限

很多时候，Azure广告组被多个应用程序使用，并且可能比您正在开发的任何一个特定应用程序的生命周期都长

在考虑嵌套组时，您可能只关心您正在开发的一个特定应用程序，并考虑组对该应用程序的访问权限。如果您计划创建的组也是非常特定于应用程序的，并且不会用于任何其他目的，那么这种方法将起作用

示例1：您的应用程序是一个博客应用程序，您在Azure广告中创建的组是查看器、参与者和管理员。（管理员>贡献者>查看器） 示例2：您有一个企业使用Azure广告，并且用户组以逻辑方式组织用户，例如部门明智的营销、人力资源、工程等

因此，您基于较低的访问权限来描述嵌套组的方式在技术上适用于较简单的场景，如示例1，但不适用于示例2，其中组更通用

很多时候，通用组已经存在，您希望重用它们，而不是为您的应用程序重新创建新的组，这些应用程序需要新的分配/成员资格，但这可能适用于您的特定情况，也可能不适用于您的特定情况

此外，可能会有多人管理这些组及其成员，因此您提出的任何设计/组织模式都应该重视直观性，即使有时您不得不牺牲一些特定于应用程序的效率

在我看来，您可以查看平面组或嵌套组。。如果从用户和组的组织的角度来看，这是有意义的，那么不仅仅是访问权限。另一个虚构的例子：

Marketing

组可以有一个成员组，如

Marketing Content Approvers

，因为它是营销人员的子集

请考虑。 它们是特定于应用程序的，与应用程序的清单相关联，可以作为令牌声明的一部分提供给您

在某些情况下，例如基于单个资源的访问，您希望向特定资源授予权限，而应用程序角色可能有意义，也可能没有意义，您仍然需要直接依赖组或用户。无论如何，这是另一个对你有用的选择

管理组（如您在评论中所问）

查看（委托v/s自助服务）以及基于属性的动态成员资格规则（尽管需要高级许可证）

@乔伊旺a