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

问题描述

假设我有一个集合 transactions 和一个策略，该策略为具有角色 user 的用户授予对该集合中的事务的读取访问, 如果用户的 department 与记录的 on 相同.

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").

如果 PDP 可以将条目列表需要由部门过滤的信息返回给 PEP，效率会更高(并且 PEP 可以将其传递给底层数据存储).

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).

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

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?

推荐答案

你提出了一个很好的观点.XACML 是为我所说的交易授权而设计的，即授权特定的交易或流程.例如:

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:

• 政策:护士可以查看其科室患者的病历.
• 请求:Joe 护士可以查看医疗记录 #123 吗?

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

挑战在于当您想要控制对大量甚至未知数量的项目的访问时.在这种情况下，您(理论上)可以只发送大量请求.您甚至可以利用 XACML 的多决策概要 允许您创建请求，例如:

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:

• 请求:Joe 护士能否查看医疗记录 #123、#124、#125、#126...?

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

然后，您会得到与请求中包含的 MDP 元素一样多的答案.你甚至可以做一个矩阵，例如

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

• 请求:Joe 护士能否查看和编辑医疗记录 #123、#124、#125、#126...?
• 响应:2x4 = 8 个决定.

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

但是，它仍然不能很好地扩展(它可以达到数千，但几乎不能达到数百万)，并且在分页场景中以及当您不知道自己有多少项目时不起作用.它在分页中不起作用，因为假设您检索将显示的 10 个项目(通过分页)，然后您授权每个项目.您可能会面临页面上少于 10 个项目而破坏用户体验的风险.

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.

在您的问题中，您提到使用义务和建议.这是一种选择，但您对缺点的看法是正确的.它在建议中隐藏了 authZ 语义，这使得单个案例更加困难.这就是你的政策将成为什么

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

这为政策执行点 (PEP) 带来了大量工作.

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

那么有什么选择呢?

Axiomatics(免责声明，是我工作的地方)在 PDP 之上提出了一个新的 API，它允许您以一种称为 反向查询.这是关于该主题的开发人员帖子.

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.

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

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

• Alice 可以看到什么?

请求可以是通用的，也可以是具体的.以下都是有效的请求:

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

• 会发生什么?
• 爱丽丝能做什么?
• Alice 可以看到什么?
• Alice 可以查看哪些病历?
• Alice 可以查看急诊科的哪些病历?
• ...

响应将是根据必须满足的策略计算出的一组过滤器表达式.

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

鉴于之前所述的政策

• 政策:护士可以查看其科室患者的病历.
• 用户元数据:Alice 是芝加哥库克县医院肿瘤科的一名护士.

• 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.

可能的答案是

• 会发生什么?
  • 答案:护士可以查看其科室患者的病历.
  • What can happen?
    • Answer: A nurse can view the medical record of a patient in their department.
    • 答案:查看肿瘤患者的病历.
    • Answer: view the medical record of a patient in oncology.
    • 答案:肿瘤患者的病历.
    • Answer: medical record of a patient in oncology.
    • 答案:一名肿瘤患者.
    • Answer: one of a patient in oncology.
    • 答案:没有

    上述示例中的请求主要针对 Alice.您可以专注于资源(病历)，甚至是行动.你可以选择.

    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屋！