访问控制设计模式

Question

我正在开发一个 PHP 应用程序，我想为我的一些对象添加访问控制。我没有将这个问题标记为 PHP，因为我觉得这个问题不是特定于语言的。

假设我有一个“服务类”，

abstract class Service {


}

许多服务都使用它作为基类。一个伪示例是：

class Companies extends Service {

  function getCompanyInfo($id) {
      //...
  }

}

稍后我想添加访问控制。示例“getCompanyInfoById”方法是“读取”操作，因此这需要“读取”权限。

此时我可以通过以下方式实现这一点：

1. 将访问控制添加到 Service 类。每个方法（例如 getCompanyInfoById）必须在内部调用“hasPrivilege”方法才能完成操作并返回结果。
2. 将所有 Service 对象包装在某种 Proxy 对象中，该对象将在调用内部对象中的方法之前检查权限。
3. 完全分离访问控制，并强制“调用者”在调用方法之前检查权限。

每个选项的缺点：

1. 这需要更改所有服务， 并要求他们意识到 访问控制。我觉得这样 反对关注点分离。
2. 这破坏了 OOP 功能，例如 多态性。来电者不再 知道任何服务的接口 支持。
3. 这是最灵活的，但最大的缺点是检查权限现在是隐式的。开发人员可能会“忘记”，或者复杂的代码路径可能会导致调用未经授权的服务。

有没有更好的方法来解决这个问题？

Answer 1

另一个解决方案可能是您的 1.ex 的一个小变体

。

class Service
{
  var $ACL = //some hash map with acl
}

class Companies extends Service
{

  function getCompanyById($id)
  {
    //real code
  }
}

class SafeCompanies extends Companies
{
//If a method must be "protected" with an ACL, you must override them in this way
  function getCompanyById($id)
  {
    $this->check('read'); //raise an exception if current user haven't READ privilege
    parent::getCompanyById($id);    
  }  
} 

这样你就不会混合职责，并且仍然可以使用多态性，

我的 2 美分

Answer 2

Java EE 模型几乎与 2 类似。您的代码在“容器”中运行，您向容器告知您的接口入口点（servlet 的 URL、EJB 的方法）并定义可以使用这些入口点的角色。管理员将身份验证信息（例如 LDAP 用户和组）映射到特定角色，容器在授予对入口点的访问权限时参考该映射。

这里的关键是容器“知道”你的代码，它实际上是一个非常聪明的代理。

在没有容器的情况下，我会考虑代理方法，也许使用某种面向方面的技术。

我认为你是对的，选项 3 非常脆弱，客户端程序员的责任太多。

Answer 3

十年后......世界已经发生了很大的变化，特别是出现了一种全新的范式：外部化授权。公平地说，每个开发框架都有自己的版本（例如 Ruby 中的 CanCanCan 或 Java 中的 Spring Security 或 C# 中基于声明的授权）。外部化授权旨在将授权逻辑与业务逻辑解耦。这个想法是授权需求可能独立于业务逻辑而发展。例如，您的业务逻辑提供对银行帐户的访问（查看/编辑/删除/转移）。该功能是稳定的 - 在不久的将来不会改变。然而，授权需求可能会因立法（GDPR、开放银行...）或不同的要求（委托、父子、VIP...）而发生变化，这就是您想要外部维护授权的原因。

为此，有一个名为基于属性的访问控制的模型（abac），它是更知名的基于角色的访问控制（rbac)。在 RBAC 中，访问控制是以身份为中心的。它基于用户、角色以及用户所属的组。很多时候这还不够。在ABAC中，您可以使用用户、资源、上下文（时间）和操作的属性。 ABAC 还允许您使用标准化策略语言以简单的古英语编写策略 ( xacml 或 alfa 或 Rego）。云平台（AWS 和 Google）也实现了自己的语言（分别称为 Google IAM 和 AWS IAM）。

ABAC 的一些好处包括：

• 灵活性：您可以更改授权策略，而无需触及应用程序/API
• 可重用性：您可以将相同的策略应用于数据、API、应用程序或基础设施。
• 可见性：将授权明确表示为策略，而不是硬编码逻辑，这意味着您可以轻松审核策略并了解什么是可能的/什么不是可
• 审核性：使用 ABAC，您可以获得所有已授予或拒绝的访问的单个日志。

如果您想了解更多信息，请查看 Wikipedia 页面的 ABAC 和 ALFA 以及 NIST 关于 ABAC 的页面。