XACML如何有效地控制对资源集合（列表）的访问 [英] XACML how to efficiently control Access to Collections (Lists) of Resources

问题描述

比方说，我有一个集合交易和一个策略，该策略向该集合中的交易授予读访问权限角色为 user 的用户（如果该用户的部门与记录中的记录相同）。

问题：如果我访问单个资源，则检查每个资源的访问都没有问题。但是，如果我想枚举/列出整个馆藏，我将需要检查馆藏中效率不高的每个项目（特别是如果您的条目数量为高）。

如果PDP可以将信息返回给PEP，而该条目列表需要由部门过滤（PEP可以将其传递给基础数据存储），则效率会更高。

我考虑过为此使用义务，但据我所知，它们不应包含与AuthZ相关的信息。

那么如何解决呢？

解决方案

您提出了一个很好的观点。 XACML是为 交易授权 （即特定交易或流程的授权）设计的。例如：

• 政策：护士可以查看其所在部门患者的病历。


• 请求：护士乔可以查看病历＃123吗？

面临的挑战是当您想控制对大量甚至未知数量项目的访问。在那种情况下，您可以（理论上）仅发送大量请求。您甚至可以利用 XACML的多个决策配置文件允许您创建以下请求：

• 请求：护士乔可以查看病历＃123 ，＃124，＃125，＃126 ...？

然后，您将获得与MDP元素一样多的答案。请求。您甚至可以创建矩阵，例如

• 请求：护士乔可以查看和编辑医疗记录＃123， ＃124，＃125，＃126 ...？


• 响应：2x4 = 8个决定。

但是，它仍然无法很好地扩展（可以扩展到数千个，但几乎不扩展到数百万个），并且在分页方案中以及当您不知道有多少个项目时都无法使用有。它在分页中不起作用，因为想象您检索了10个（通过分页）要显示的项目，然后授权每个项目。您冒着页面上少于10个项目的风险，这破坏了用户体验。

在您的问题中，您暗示使用义务和建议。这是一个选择，但是您对缺点是正确的。它将authZ语义隐藏在建议中，并使单个案例更难。这就是您的政策

• 政策：护士可以查看患者的病历和义务：部门过滤器

这在策略执行点（PEP）上进行了大量工作。 / p>

那还有什么选择？

使用反向查询（ARQ）

公理学（免责声明-是我工作的地方）在PDP之上提出了一个新API，可让您以开放式方式查询策略，称为反向查询。这是有关该主题的开发人员帖子。

不是发送完整的XACML请求，而是发送部分请求（一个开放式问题），例如

• 爱丽丝可以看什么？

请求可以是通用的也可以是特定的需要。以下是所有有效请求：

• 会发生什么？


• 爱丽丝能做什么？ / li>
  
• 爱丽丝可以查看什么？


• 爱丽丝可以查看哪些病历？


• 急诊科的哪些病历Alice可以查看吗？


• ...

响应将是一组过滤器表达式

鉴于先前所述的政策

• 政策：护士可以查看其所在部门的患者病历。


• 用户元数据：爱丽丝是芝加哥库克县医院的一名护士肿瘤科。

可能的答案是

• 会发生什么？
  
  
  
  
  • 答案：护士可以查看其所在部门患者的病历。
  
  


• 爱丽丝能做什么？
  
  
  
  
  • 答案：查看肿瘤患者的病历。
  
  


• 爱丽丝可以看到什么？
  
  
  
  
  • 答案：肿瘤科患者的病历。
  
  


• 爱丽丝可以查看哪些病历？
  
  
  
  
  • 答案：一位肿瘤学患者。
  
  


• 爱丽丝可以查看急诊室的哪些病历？
  
  
  
  
  • 答案：无
  
  

上述示例中的请求主要针对Alice。您本来可以专注于资源（病历）甚至行动。您可以选择。

我希望这对您有帮助，David
。

Let's say I have a collection transactions and a policy that grants read access to a transaction within that collection for users with the role user, if the user's department is the same as the on of the record.

The Problem: If I access single resources I have no problem checking access per resource. But if I want to enumerate/ list the whole collection I would need to check each and every item in the collection which is not efficient (especially if you amount of entries is "high").

It would be more efficient, if the PDP could return the information to the PEP that the list of entries needs to be filtered by the department (and the PEP could pass this on to the underlying data store).

I thought about using obligations for this but as far as I can see they should not contain AuthZ relevant information.

So how can this be tackled?

解决方案

You bring up an excellent point. XACML was designed for what I would call transactional authorization i.e. authorization a specific transaction or flow. For instance:

• Policy: A nurse can view the medical record of a patient in their department.
• Request: Can Joe the nurse view medical record #123?

The challenge is when you want to control access to a large or even an unknown number of items. In that case, you could (in theory) just send a large number of requests. You could even leverage the Multiple Decision Profile of XACML which allows you to create requests such as:

• Request: Can Joe the nurse view medical record #123, #124, #125, #126...?

You then get back as many answers as you had MDP elements in the request. You can even do a matrix e.g.

• Request: Can Joe the nurse view and edit medical record #123, #124, #125, #126...?
• Response: 2x4 = 8 decisions.

However, it still does not scale that well (it can go up to the thousands but hardly millions) and it won't work in pagination scenarios and when you do not know how many items you have. It does not work in pagination because imagine you retrieve 10 items (via pagination) that you will display and then you authorize each one. You run the risk of having less than 10 items on your page which breaks the user experience.

In your question, you allude to using obligations and advice. That is an option but you are right about the drawback. It hides authZ semantics inside the advice and it makes the single case harder. This is what your policy would become

• Policy: A nurse can view the medical record of a patient + obligation: filter on department

This puts a lot of work on the Policy Enforcement Point (PEP).

So what's the alternative?

Using Reverse Query (ARQ)

Axiomatics (which - disclaimer - is where I work) came up with a new API on top of the PDP that lets you query policies in an open-ended way called the Reverse Query. Here is a developer post on the topic.

Rather than sending in a full-blown XACML requests, you send in a partial request (an open-ended question) e.g.

• What can Alice view?

The request can be as generic or as specific as need be. The following are all valid requests:

• What can happen?
• What can Alice do?
• What can Alice view?
• Which medical record can Alice view?
• Which medical record in department ER can Alice view?
• ...

The response will be a set of filter expressions computed from the policies that must be met.

Given the policy previously stated

• Policy: A nurse can view the medical record of a patient in their department.
• User metadata: Alice is a nurse at Cook County Hospital in Chicago in the oncology department.

Possible answers would be

• What can happen?
  • Answer: A nurse can view the medical record of a patient in their department.
• What can Alice do?
  • Answer: view the medical record of a patient in oncology.
• What can Alice view?
  • Answer: medical record of a patient in oncology.
• Which medical record can Alice view?
  • Answer: one of a patient in oncology.
• Which medical record in department ER can Alice view?
  • Answer: nothing

The requests in the example aforementioned focus on Alice. You could have focused on the resource (medical record) instead or even the action. You get to choose.

I hope this helps, David.

这篇关于XACML如何有效地控制对资源集合（列表）的访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！