XACML 3.0 和多种资源
XACML 3.0 and Multiple Resources
我正在尝试弄清楚如何使用 Balana 的 XACML 实现来实现授权机制(WSO2 的授权引擎基于 Balana)。
当用户请求访问单个资源时(例如,鲍勃想要阅读病历),事情就很简单了。
但是,假设鲍勃想要阅读他所有患者的病历。这里的第一个问题是需要有一种方法来弄清楚谁是他的病人。我还需要获取他的患者的每条记录的属性。问题是,我试图解决这种情况,同时将对我的 PIP 的属性请求数量保持在最低限度。
重新表述我的目标:我正在尝试根据属性 returned 评估 Bob 是否可以访问多个医疗记录(创建决策请求时记录是未知的)由 PIP(例如,我希望我的 PIP 与数据库的交互尽可能少)。
简而言之,我发现当尝试使用 XACML 控制对资源集合的访问时,事情会变得棘手。
我在这里找到了几个选项:
我的请求包含主题、操作、资源 ID 和范围。我使用 XACML 多重决策配置文件:PDP 知道 children/descendant 资源是有针对性的,因此它将为每个 child/descendant 创建多个评估上下文(但尚未找到资源的属性)。然后,使用 PIP,它将检索每个单独评估上下文的属性(例如,获取 bob 的医生 ID,然后获取每个单独资源的医生 ID)。例如,如果我的 PIP 正在查询数据库,它将针对每个单独的请求对每个单独的属性执行大量查询,因此会对性能产生很大影响。
我的请求包含主题、操作、资源 ID。我不再使用多重决策配置文件。然而,在创建评估上下文并要求 PDP 评估我的请求之前,我知道我的资源实际上是一个集合,所以我以某种方式获得了所有 children/descendants 及其所有属性,只有在我获得所有这些信息之后,我手动为每个 child/descendant 创建单独的决策请求,并在其中填充所有相应的属性。所以我给 PDP 一个胖决策请求,它包含几乎所有必要的属性。因为决策请求几乎具有评估上下文中的所有属性,所以不需要对我的 PIP 进行审问。这样做的好处是,我在 PDP 评估决策之前就获得了所有信息,因此 PIP 必须做的工作保持在最低限度。但是,我不确定我是否应该在到达 PDP 之前找到 children/descendants 及其所有属性(如 XACML 规范所述,在上下文处理程序中的某处)。
我的请求包含主题、操作、资源 ID。我使用多重决策配置文件。我有一个可以找到 Children/Descendant 资源和一些 PIP 的组件。所有这些组件都使用一个存储库,假设称为 MedicalRecordsRepository。此 repo 在请求 children/descendant ID 时,还会从数据库中获取所有属性并将所有这些信息存储在缓存中。因此,之后,当有多个单独评估的评估上下文时,如果 PIP 被请求 return 一个属性,它将从 repo 的缓存中获取该属性。因此,数据库交互保持在最低限度。但是,问题是存储库组件及其缓存。
我已经阅读了规范,我四处寻找,但我还没有找到解决这个问题的方法。有人有什么想法吗?
提前致谢!
In a nutshell, what I've discovered is that when attempting to control access to a collection of resources with XACML, things get tricky.
你是对的。 XACML 很好地解决了事务和功能访问控制。它不能很好地处理数据访问控制。
- 交易访问控制:Alice 可以查看病历 #1 吗?
- 功能访问控制:爱丽丝可以查看医疗记录吗?
- 数据访问控制:Alice 可以查看哪些医疗记录?
我不确定我是否完全掌握了你的三种方法,但你确实强调了相关问题
- 不知道有多少项目
- 从外部属性源检索属性(假设每个医疗记录有 10 个属性乘以 1,000,000 条记录 - 即 10M 次查找)
根据我的经验,当您有数千个请求时,多个决策配置文件请求效果很好。除此之外,我会考虑 Axiomatics Reverse Query(免责声明 - 我为 Axiomatics 工作)。反向查询通过公开一个 API 来解决您的问题,让您可以提出开放式问题,例如
- 爱丽丝可以查看哪些医疗记录?
响应将是必须满足的一组条件。例如,如果以下是您的保单(使用 ALFA 符号):
使用 ALFA 表示法的 XACML 策略
policy accessMedicalRecord{
target clause com.axiomatics.examples.actionId == "view" and objectType == "medical record"
apply firstApplicable
/**
* Doctors can view medical records of patients they are assigned to
*/
rule allowRegularAccess{
target clause user.role == "doctor"
condition patient.assignedDoctor == user.identifier
permit
}
}
ARQ 请求/响应示例
- 请求:Alice医生可以查看哪些病历?
- 响应:如果
patient.assignedDoctor == "Alice"
则允许
答案可以翻译成查询语言,例如SQL:
SELECT id FROM MED_RECORDS WHERE assignedDoc = 'Alice';
它也可以是另一种查询语言。然后您可以使用它来查询数据的来源,例如a SQL 数据库并检索相关病历。
另请参阅此 。
我正在尝试弄清楚如何使用 Balana 的 XACML 实现来实现授权机制(WSO2 的授权引擎基于 Balana)。
当用户请求访问单个资源时(例如,鲍勃想要阅读病历),事情就很简单了。
但是,假设鲍勃想要阅读他所有患者的病历。这里的第一个问题是需要有一种方法来弄清楚谁是他的病人。我还需要获取他的患者的每条记录的属性。问题是,我试图解决这种情况,同时将对我的 PIP 的属性请求数量保持在最低限度。
重新表述我的目标:我正在尝试根据属性 returned 评估 Bob 是否可以访问多个医疗记录(创建决策请求时记录是未知的)由 PIP(例如,我希望我的 PIP 与数据库的交互尽可能少)。
简而言之,我发现当尝试使用 XACML 控制对资源集合的访问时,事情会变得棘手。
我在这里找到了几个选项:
我的请求包含主题、操作、资源 ID 和范围。我使用 XACML 多重决策配置文件:PDP 知道 children/descendant 资源是有针对性的,因此它将为每个 child/descendant 创建多个评估上下文(但尚未找到资源的属性)。然后,使用 PIP,它将检索每个单独评估上下文的属性(例如,获取 bob 的医生 ID,然后获取每个单独资源的医生 ID)。例如,如果我的 PIP 正在查询数据库,它将针对每个单独的请求对每个单独的属性执行大量查询,因此会对性能产生很大影响。
我的请求包含主题、操作、资源 ID。我不再使用多重决策配置文件。然而,在创建评估上下文并要求 PDP 评估我的请求之前,我知道我的资源实际上是一个集合,所以我以某种方式获得了所有 children/descendants 及其所有属性,只有在我获得所有这些信息之后,我手动为每个 child/descendant 创建单独的决策请求,并在其中填充所有相应的属性。所以我给 PDP 一个胖决策请求,它包含几乎所有必要的属性。因为决策请求几乎具有评估上下文中的所有属性,所以不需要对我的 PIP 进行审问。这样做的好处是,我在 PDP 评估决策之前就获得了所有信息,因此 PIP 必须做的工作保持在最低限度。但是,我不确定我是否应该在到达 PDP 之前找到 children/descendants 及其所有属性(如 XACML 规范所述,在上下文处理程序中的某处)。
我的请求包含主题、操作、资源 ID。我使用多重决策配置文件。我有一个可以找到 Children/Descendant 资源和一些 PIP 的组件。所有这些组件都使用一个存储库,假设称为 MedicalRecordsRepository。此 repo 在请求 children/descendant ID 时,还会从数据库中获取所有属性并将所有这些信息存储在缓存中。因此,之后,当有多个单独评估的评估上下文时,如果 PIP 被请求 return 一个属性,它将从 repo 的缓存中获取该属性。因此,数据库交互保持在最低限度。但是,问题是存储库组件及其缓存。
我已经阅读了规范,我四处寻找,但我还没有找到解决这个问题的方法。有人有什么想法吗? 提前致谢!
In a nutshell, what I've discovered is that when attempting to control access to a collection of resources with XACML, things get tricky.
你是对的。 XACML 很好地解决了事务和功能访问控制。它不能很好地处理数据访问控制。
- 交易访问控制:Alice 可以查看病历 #1 吗?
- 功能访问控制:爱丽丝可以查看医疗记录吗?
- 数据访问控制:Alice 可以查看哪些医疗记录?
我不确定我是否完全掌握了你的三种方法,但你确实强调了相关问题
- 不知道有多少项目
- 从外部属性源检索属性(假设每个医疗记录有 10 个属性乘以 1,000,000 条记录 - 即 10M 次查找)
根据我的经验,当您有数千个请求时,多个决策配置文件请求效果很好。除此之外,我会考虑 Axiomatics Reverse Query(免责声明 - 我为 Axiomatics 工作)。反向查询通过公开一个 API 来解决您的问题,让您可以提出开放式问题,例如
- 爱丽丝可以查看哪些医疗记录?
响应将是必须满足的一组条件。例如,如果以下是您的保单(使用 ALFA 符号):
使用 ALFA 表示法的 XACML 策略
policy accessMedicalRecord{
target clause com.axiomatics.examples.actionId == "view" and objectType == "medical record"
apply firstApplicable
/**
* Doctors can view medical records of patients they are assigned to
*/
rule allowRegularAccess{
target clause user.role == "doctor"
condition patient.assignedDoctor == user.identifier
permit
}
}
ARQ 请求/响应示例
- 请求:Alice医生可以查看哪些病历?
- 响应:如果
patient.assignedDoctor == "Alice"
则允许
答案可以翻译成查询语言,例如SQL:
SELECT id FROM MED_RECORDS WHERE assignedDoc = 'Alice';
它也可以是另一种查询语言。然后您可以使用它来查询数据的来源,例如a SQL 数据库并检索相关病历。
另请参阅此