基于权限的自定义 ACL 授权和 return 行
Custom ACL Authorization and return rows based on the permission
我正在构建某种复杂的库存系统，接受供应商的报价等。
通常我会有像 Read/Write/Edit/Delete 这样的基本权限，我可以轻松地更新每个页面上的读写 bool 变量，以检查是否为 true 执行此操作，否则执行那个操作。
但事实并非如此。我有一些权限，比如 (Owner, SamePseudoCity) 这分别意味着允许用户访问他只创建的记录，另一个意味着返回属于 PsuedoCity 作为用户的记录。
目前 UI 具有具有适用权限的局部变量，当 UI 从数据库请求一些数据时，它会调用首先获得用户有权获得的权限并绑定它们的 BL到 UI/Page 个局部变量。
同时检查权限列表是否包含'Owner'则获取该UserID创建的记录，如果包含'SamePseudoCity'则获取同城的所有记录
我不确定这是否是一个好的设计，我是否可以修改它。我知道这里没有对错之分，但有臭味设计、好的设计和更好的设计。所以我只是在寻找一些想法，如果有人以前实现过这个。
我花了很多时间来解释我的问题，如果仍然不清楚，请告诉我，我可以 post 从我的代码中提取一些片段。
掌握您的要求
您需要的是一个足以处理您的要求的授权框架。在你的 post 中，你提到你有
- 权限，例如Read/Write/Edit/Delete
- 其他参数，例如Owner, SamePseudoCity 这意味着不同的东西：
- 允许用户访问他只创建的记录
- 作为用户返回属于 PsuedoCity 的记录。
Attribute-based访问控制
您需要转向 [tag: ABAC]（基于属性的访问控制），这将使您能够使用属性（key-value 对）和策略来定义您的要求。这些策略在称为策略决策点 (PDP) 的第 3 方引擎中进行维护和评估。
ABAC 是由 NIST 定义的标准。它是 RBAC（role-based 访问控制）的演变。 XACML，可扩展访问控制标记语言是 ABAC 的一种实现，
您可以将 abac 应用于架构中的不同层，从 UI（表示层）到业务层，一直到数据层。
示例：
namespace Whosebug{
你先定义你的属性
namespace user{
attribute identifier{
category = subjectCat
id = "user.identifier"
type = string
}
attribute city{
category = subjectCat
id = "user.city"
type = string
}
}
namespace item{
attribute owner{
category = resourceCat
id = "item.owner"
type = string
}
attribute city{
category = resourceCat
id = "item.city"
type = string
}
}
attribute actionId{
category = actionCat
id = "actionId"
type = string
}
然后定义使用这些属性的策略
/**
* Control access to the inventory
*/
policy inventory{
apply firstApplicable
/**
* Anyone can view a record they own
*/
rule viewRecord{
target clause actionId == "view"
condition user.identifier == item.owner
permit
}
/**
* Anyone can view a record that is in the same city
*/
rule viewRecordsSameCity{
target clause actionId == "view"
condition user.city == item.city
permit
}
}
}
下一步
然后您需要部署策略决策点/策略服务器。您可以从以下几个选项中选择：
- Axiomatics 策略服务器（我在 Axiomatics 工作的免责声明）
- SunXACML
- Oracle 权利服务器
- WSO2 身份服务器
如果您想将策略应用于 UI 和数据库，则可以通过名为 动态数据屏蔽 的 Axiomatics 产品使用名为 Data Access Filter MD.
更新
OP 后来评论如下
ABAC" never heard of it and it sounds brilliant but I assume I need access to a dedicated server or a VPS to install the PDP, right ? .. I know this can be too much to ask but I have 3 questions, Can I programmatically change the rules ? Is it possible to implement this scenario where Every product has a pseudo city and every manager also has a pseudo city and managers are only allowed access to their own city products ? is it possible do simple read/write/edit rules and hide and show UI based on that ? –
那么首先，让我们从 ABAC 架构图开始：
- PEP 是策略执行点，负责保护您的应用程序、APIs 和数据库。它执行授权决定。
- PDP 是策略决策点，负责评估策略和做出决策。它处理从 PEP 收到的请求和 returns 授权决定（允许、拒绝）。
- PAP 是您定义和管理策略的策略管理点
- PIP是策略信息点。它是 PDP 用来连接第三方属性源的接口，例如用户 LDAP、数据库或 Web 服务。 PDP 在需要了解有关用户或资源的更多信息时使用 PIP。
I assume I need access to a dedicated server or a VPS to install the PDP, right ?
是的，您会在服务器（或云端）上安装 PDP。它成为您基础架构的一部分。
Can I programmatically change the rules?
是的，你可以。 Axiomatics PAP 有一个 API，您可以使用它以编程方式上传、导出和创建策略。
Is it possible to implement this scenario where Every product has a pseudo city and every manager also has a pseudo city and managers are only allowed access to their own city products ?
是的，这实际上就是我在原始示例中所写的内容，这就是 ABAC 的美妙之处。您编写一个无论城市数量如何都有效的策略：A user can view a record if user.city==record.city
is it possible do simple read/write/edit rules and hide and show UI based on that ?
是的，您可以在策略中使用任意数量的属性。因此，例如您可以：
- 拒绝用户访问他们所在城市以外的记录
- 用户可以查看记录
- 用户可以编辑他们拥有的记录
- 用户可以批准他们不拥有的记录
您可以使用逻辑在您的 UI 或您的业务层甚至数据层中驱动授权。所以你可以问 PDP：
- 我可以显示编辑按钮吗？
- 我可以显示详细信息按钮吗？
- 我可以显示“删除”按钮吗？
我正在构建某种复杂的库存系统，接受供应商的报价等。
通常我会有像 Read/Write/Edit/Delete 这样的基本权限，我可以轻松地更新每个页面上的读写 bool 变量，以检查是否为 true 执行此操作，否则执行那个操作。
但事实并非如此。我有一些权限，比如 (Owner, SamePseudoCity) 这分别意味着允许用户访问他只创建的记录，另一个意味着返回属于 PsuedoCity 作为用户的记录。
目前 UI 具有具有适用权限的局部变量，当 UI 从数据库请求一些数据时，它会调用首先获得用户有权获得的权限并绑定它们的 BL到 UI/Page 个局部变量。
同时检查权限列表是否包含'Owner'则获取该UserID创建的记录，如果包含'SamePseudoCity'则获取同城的所有记录
我不确定这是否是一个好的设计，我是否可以修改它。我知道这里没有对错之分，但有臭味设计、好的设计和更好的设计。所以我只是在寻找一些想法，如果有人以前实现过这个。
我花了很多时间来解释我的问题，如果仍然不清楚，请告诉我，我可以 post 从我的代码中提取一些片段。
掌握您的要求
您需要的是一个足以处理您的要求的授权框架。在你的 post 中，你提到你有
- 权限，例如Read/Write/Edit/Delete
- 其他参数，例如Owner, SamePseudoCity 这意味着不同的东西：
- 允许用户访问他只创建的记录
- 作为用户返回属于 PsuedoCity 的记录。
Attribute-based访问控制
您需要转向 [tag: ABAC]（基于属性的访问控制），这将使您能够使用属性（key-value 对）和策略来定义您的要求。这些策略在称为策略决策点 (PDP) 的第 3 方引擎中进行维护和评估。
ABAC 是由 NIST 定义的标准。它是 RBAC（role-based 访问控制）的演变。 XACML，可扩展访问控制标记语言是 ABAC 的一种实现，
您可以将 abac 应用于架构中的不同层，从 UI（表示层）到业务层，一直到数据层。
示例：
namespace Whosebug{
你先定义你的属性
namespace user{
attribute identifier{
category = subjectCat
id = "user.identifier"
type = string
}
attribute city{
category = subjectCat
id = "user.city"
type = string
}
}
namespace item{
attribute owner{
category = resourceCat
id = "item.owner"
type = string
}
attribute city{
category = resourceCat
id = "item.city"
type = string
}
}
attribute actionId{
category = actionCat
id = "actionId"
type = string
}
然后定义使用这些属性的策略
/**
* Control access to the inventory
*/
policy inventory{
apply firstApplicable
/**
* Anyone can view a record they own
*/
rule viewRecord{
target clause actionId == "view"
condition user.identifier == item.owner
permit
}
/**
* Anyone can view a record that is in the same city
*/
rule viewRecordsSameCity{
target clause actionId == "view"
condition user.city == item.city
permit
}
}
}
下一步
然后您需要部署策略决策点/策略服务器。您可以从以下几个选项中选择：
- Axiomatics 策略服务器（我在 Axiomatics 工作的免责声明）
- SunXACML
- Oracle 权利服务器
- WSO2 身份服务器
如果您想将策略应用于 UI 和数据库，则可以通过名为 动态数据屏蔽 的 Axiomatics 产品使用名为 Data Access Filter MD.
更新
OP 后来评论如下
ABAC" never heard of it and it sounds brilliant but I assume I need access to a dedicated server or a VPS to install the PDP, right ? .. I know this can be too much to ask but I have 3 questions, Can I programmatically change the rules ? Is it possible to implement this scenario where Every product has a pseudo city and every manager also has a pseudo city and managers are only allowed access to their own city products ? is it possible do simple read/write/edit rules and hide and show UI based on that ? –
那么首先，让我们从 ABAC 架构图开始：
- PEP 是策略执行点，负责保护您的应用程序、APIs 和数据库。它执行授权决定。
- PDP 是策略决策点，负责评估策略和做出决策。它处理从 PEP 收到的请求和 returns 授权决定（允许、拒绝）。
- PAP 是您定义和管理策略的策略管理点
- PIP是策略信息点。它是 PDP 用来连接第三方属性源的接口，例如用户 LDAP、数据库或 Web 服务。 PDP 在需要了解有关用户或资源的更多信息时使用 PIP。
I assume I need access to a dedicated server or a VPS to install the PDP, right ?
是的，您会在服务器（或云端）上安装 PDP。它成为您基础架构的一部分。
Can I programmatically change the rules?
是的，你可以。 Axiomatics PAP 有一个 API，您可以使用它以编程方式上传、导出和创建策略。
Is it possible to implement this scenario where Every product has a pseudo city and every manager also has a pseudo city and managers are only allowed access to their own city products ?
是的，这实际上就是我在原始示例中所写的内容，这就是 ABAC 的美妙之处。您编写一个无论城市数量如何都有效的策略：A user can view a record if user.city==record.city
is it possible do simple read/write/edit rules and hide and show UI based on that ?
是的，您可以在策略中使用任意数量的属性。因此，例如您可以：
- 拒绝用户访问他们所在城市以外的记录
- 用户可以查看记录
- 用户可以编辑他们拥有的记录
- 用户可以批准他们不拥有的记录
您可以使用逻辑在您的 UI 或您的业务层甚至数据层中驱动授权。所以你可以问 PDP：
- 我可以显示编辑按钮吗？
- 我可以显示详细信息按钮吗？
- 我可以显示“删除”按钮吗？