在 Web API/OWIN 中使用大量声明的最佳实践

Posted 2023-03-14

【中文标题】在 Web API/OWIN 中使用大量声明的最佳实践

【英文标题】：Best practices for using large list of claims in Web API/OWIN

【发布时间】：2014-12-13 02:11:27

【问题描述】：

我正在尝试使用 Web API/OWIN/OAuth 实现基于声明的授权设置，并且我正在尝试找出管理更细粒度授权类型的最佳方法。

我不喜欢只使用角色的想法，因为我正在处理的应用程序中需要大量细粒度的授权。我在想角色+权限的方法更有意义（角色只是映射到权限的子集）。权限将基于操作+资源对（例如 CanViewEmployee、CanEditEmployee 等）。这里没有什么不寻常的地方。

但是，我想知道这应该如何使用 OWIN/OAuth 来实现，可能使用 Thinktecture IdentityServer。我试图避免在我拥有的自定义 AuthorizationManager 中对权限进行硬编码，因为它们需要在不重新构建的情况下轻松更改。我知道将这些作为策略放在 web.config 中是一种选择（将资源+操作映射到声明类型和值），但是如果我们谈论的是几十个，甚至是几百个权限，这似乎可以得到很快就会失控。

我想第三种选择是从数据库中驱动它，但从那里管理它也需要某种前端来做到这一点，这比仅仅更改配置/XML 文件更费力。

当涉及大量声明/权限时，我是否遗漏了其他一些选项/最佳实践，或者当数字失控时我可以使用其他一些实用程序或软件包来帮助管理这个问题？

【参考方案1】：

将这些权限解耦到一个单独的授权管理器类是一个很好的第一步。然后，您可以在该代码中硬编码您的权限规则（例如“管理员”角色可以执行操作 X、Y 和 Z，但只有“经理”角色可以执行 X 或 Y）。但是您也可以让授权管理器中的代码执行动态查找以检查已在数据库中设置的权限（例如）。

在代码中执行此操作的另一个好处是您可以对其进行单元测试，以证明您的权限逻辑已正确实现（因此将在运行时正确执行）。如果您的权限确实经常更改，这将很有用。

此外，如果您需要频繁重新部署（因为频繁更改），解耦将有所帮助，因为可以将代码隔离到自己的程序集中。

【讨论】：

是的，我明白这一点，但我想弄清楚这是否是管理大量权限的最佳方式。我想避免在代码中这样做，以避免在权限（不可避免地）更改时避免代码搅动和重建，并避免有数百行带有规则的代码，所以我一直倾向于在数据库中这样做，以便我们可以通过管理屏幕动态更改它们。我只是想确保我没有遗漏任何东西，并且没有更好的选择。

已更新以增加单元测试和隔离以实现频繁更新的好处。至于频繁更改的权限——很难说。也许那些应该是数据库而不是代码中的标志。

是的，我当然更倾向于 DB。感谢您的信息！