基于分层角色的访问控制系统

Question

企业需要一个非常复杂的访问控制系统，在该系统中，会在运行时基于多个条件为用户授予/拒绝权限。只是为了让您了解一下一些资源的规则，例如。

• 可以查看列表
• 可以查看详细信息
• 可以查看详细信息页面，但看不到电子邮件地址/电话号码字段
• 可以编辑完整文档
• 只能编辑电话号码，但不能将其设置为空作为新值。
• 可以完全删除记录
• 仅当仍不是学员时才能打印页面

我希望你明白。大约有100多个资源，每个资源都有20到90个类似的规则。

考虑到系统的巨大规模和复杂性，我的团队决定构建一个基于角色的分层访问控制系统，下面是我们如何计划解决该问题的想法。

• 为每个角色使用一个简单的类

• 使用反向命令链并为当前角色继承自

的角色添加引用

• 当前角色类仅处理当前类唯一的权限。然后一直沿向上（在现实生活中一直向下）以计算完整权限图。

• 使用装饰器处理跨领域问题的运行时计算，例如，如果用户是受训者或他仍处于试用期，则限制删除权限，或者在用户辞职并刚刚完成其最后一天时限制访问权限公司。

举个例子，用户是经理，但处于试用期  时间，他想访问客户的详细信息。这是伪代码

CountryManagerPermnissionsSpec()
{
    immediate_subordinates = ["RegionalManager", "ManagerHR"];
    accessible_resources = [
        "Finance": ["LIST", "DETAIL", "TRANSACTION_HISTORY", "REPORTS"] 

   ]

}

// class to limit the permissions when user is still under training 
TraineeUserPermissionsSpec()
{
     blocked_activites = ["delete", "bulk delete", "direct client message"];


}

跳过实施细节，我们可以如下计算当前用户权限

new acl
acl->addRole(ContryManager)
acl->addRole(Trainee)

can_see_data = UserCanViewDataSpec(user, acl)

现在我的问题是，这导致我们进入了许多微小但可测试的类，这对我们来说不是问题，但这是处理此类问题的正确方法吗？有更好的替代品吗？

我不认为这很重要，但是以防万一，当前的系统是用php构建的。