在阅读有关ACL和RBAC的信息时，我似乎很容易理解-可以使用用户名或角色来访问资产。我还可以看到如何实现这些目标。

即，此图像为我提供了ACL和RBAC的清晰视图（如上图所示，我可以继续设计数据库表）：（ 图像由pressbooks提供）

我正在努力的是ABAC。到目前为止，我发现的各种图像都是手工绘制的，或者过于复杂，或者建议使用第三方外部实体进行授权。还是给出奇怪的属性示例，我并不完全确定该如何使用。

起始范例

因此，让我从现实生活中入手。假设我有一家拥有70-200人的公司。我要保护的资产是一个包含许多不同页面的网站。我希望允许某些人使用某些资产。

例如，我希望某人Leslie可以访问名为的网页Price Manager，并只允许该人管理Travel该页面上价格组的价格，而不能管理Product同一页面上组的价格。我将如何使用ABAC实施此操作？

到目前为止，我猜测是我可以分配Leslie一些属性（但是哪些属性是什么？这些属性是什么？），然后有一个存储这些属性的数据库表。然后，我可以设计一个引擎，查看这些属性（但不像LeslieRBAC那样将其视为“角色”），并从中决定是否授予对该页面的访问权限。该引擎的外观如何？这是一个简单的if / else块吗？还有吗

如果莱斯利后来改变立场，而有人需要更改访问权限，会发生什么情况？如果她需要转移访问权限Product并撤消访问权限，将会是什么样Travel？如何将它，如果她需要访问撤销的编码Price Manager页共，因此没有再访问没有Travel，或者Product？

在我的案例中，资产只是为了重述Price Manager，而用户可以访问该页面上的各种价格组，例如Travel定价，Product定价等。

我正在寻找的是一个合理的完整路线图，以澄清细节并实现实现，我可以不加猜测地实施它。也就是说，它可以在概念上完成和/或具有我可以可视化数据库结构的特定示例，等等。

好处：ABAC是否是满足相对较小的许可需求（例如，管理70-200个人并访问约150-450资产）的正确方法？坚持使用ACL / RBAC会更好吗？

ABAC实现比ACL / RBAC更复杂。一些框架甚至为您提供了一些基础设施来应对后者。如果可以将人员和资产按相对较小的固定数量的角色/类别进行分组，那么最好坚持使用ACL / RBAC。如果每个人的权限差异很大，那么ABAC可以提供更好，更灵活的解决方案。

如果您选择沿着ABAC道路走，那么您要做的第一件事就是花一些时间阅读和理解XACML标准。本文档中提供的示例使用XACML兼容语法，一开始很难理解。我猜您不想实现标准的兼容解决方案，因此您只需要其中的一般想法。

概念

XACML围绕着4个概念及其属性：主题，动作，资源和环境。还有一些，但是这些是最重要的。其他一切都建立在它们之上。如果我要用这些概念来造句，可能是这样的：主题在特定环境中对资源执行操作。将其应用于您的方案将转化为以下内容：

• 莱斯利（Leslie）打开价格管理器网页。
• 莱斯利使用价格管理器网页创建旅行价格。

属性集合

我们需要做的第一件事是收集上述概念的相关属性。理想情况下，您不应分配任何特定的属性，因为XACML会尝试不引人注目并且仅依赖于系统自然提供的功能。因此，我们有：

学科

系统中的任何参与者，无论是个人还是服务。我们的主题是莱斯利。唯一标识莱斯利需要哪些属性？或许以下一些：first name，last name，e-mail，ssn，company id，position(s)。

行动

对象执行的任何动作。可以是标准的CRUD操作，也可以是更复杂的操作。我们的行动是open/view和create。根据您使用的Web应用程序框架，这些操作的属性可以不同。在获得资源时，我们将详细讨论这一点。

资源资源

很自我解释。我们的资源是price manager page，travel prices和the newly created price。如果您真的愿意的话，还可以有更多。您可能希望隐藏用户无法执行的操作。例如。在create price button可以是可以显示/基于用户是否有权限创建价格隐藏的资源。由于用户查看价格列表的唯一方法可能是通过此页面，因此最好在此级别上执行授权，而不是在堆栈中进行进一步的选择。

对资源的访问是最复杂的实现，尤其是对来自数据库的资源。更细粒度的选项是行级安全性。一些数据库对此有一定程度的支持。一些XACML实现者甚至还创建了SQL超集。这实际上取决于您的授权需求，但是您不想做的一件事就是从表中提取所有内容，然后决定要显示的内容。您可以按权限集对资源进行分组，将其抽象到API之后，并在API端点强制执行授权。

环境

我不能正确定义它（XACML也没有正确的定义），但可以说这是发生所有这些情况的“泡泡”。这包括：web application，web server，operating system，browser，office。您可以提取属性，如：ip address，time of day，user locale，user agent，operating system version。您甚至可以使用它们来阻止用户访问应用程序不支持的环境（例如，旧的浏览器，旧的操作系统，网络之外的计算机，在工作时间以外访问）。

授权请求

收集了所有必需的属性后，我们将它们组合在授权请求中，然后将其转发给可以根据这些属性的值进行授权决策的实体。在XACML语言中，收集这些属性并执行随后做出的决策的地方称为策略实施点（PEP），而做出决策的地方称为策略决策点（PDP）。从中获得属性值的位置称为策略信息点（PIP）。PEP，PDP和PIP可以是您的应用程序的一部分，它们可以是外部系统。您可以在XACML标准中找到它们之间如何通信的图表。

决策过程

决策过程基于规则。规则可以分为策略，也可以进一步分为策略集。每个都有一个目标。目标用于确定是否有任何规则适用于授权请求。将其视为过滤器。目标包含使用属性名称和值构建的条件。例如，您的应用程序规则可以分为以下几类：

Web应用程序（策略集）
|-目标：application-name ==“ Web应用程序”
`-版本1.0（策略集）
    |-目标：application-version ==“ 1.0”
    `-查看价格经理（政策）
        |-目标：网页名称==“价格管理器” &&操作名称==“视图”
        `-张国荣可以查看价格经理（规则）
            |-目标：主题名称==“莱斯利”
            `-许可：允许

PDP将上述集合中的所有内容与授权请求中的属性值进行匹配。如果没有匹配的规则会发生什么，取决于您PDP的实现。一旦PDP已经做出了决定（allow，deny或not-applicable）其发送回它通过授予或拒绝对资源的访问后，它作用于PEP。随着反应的PDP可以发送列表obligations和advices使PEP葡萄汁或在执法过程中应当履行。根据规则的存储方式（文本文件或数据库），管理员可以使用标准的文本编辑器或自定义编辑应用​​程序根据需要更改它们。撤消Leslie对价格经理的访问权限后allow，只需将许可从更改为deny，只要PEP能够胜任。

执法

这在很大程度上取决于您的技术堆栈。某些Web框架具有自然的执行点（例如ASP.NET MVC具有属性过滤器）。您的业​​务层可能必须定义此类实施点。我发现在服务（例如微服务）端点或UI级别应用强制实施更加容易。

其他福利

实施此操作的一个很好的副作用是，您最终获得了相当丰富的审计跟踪，该审计跟踪可用于其他目的。