如何跨多个应用程序实施授权策略?

时间:2011-07-29 13:12:20

标签: web-services authorization distributed access-control

背景

我有一个后台管理各种来源的信息。部分信息位于后台可以直接访问的数据库中,部分信息通过访问Web服务进行管理。此类服务通常提供CRUD操作和分页搜索。

有一个访问控制系统可以确定允许用户执行哪些操作。用户是否可以执行某些操作的决定由依赖于基础数据模型的授权规则定义。例如。有一条规则允许用户编辑资源,如果她是该资源的所有者,其中所有者是资源表中的列。还有其他规则,例如“如果该资源属于组织且用户是该组织的成员,则用户可以编辑资源”。 当域模型可直接用于访问控制系统时,此方法很有效。它的主要优点是避免复制域模型中已存在的信息。

当要处理的数据来自Web服务时,此方法会引发问题。我可以看到下面将讨论的各种方法。

在服务中实施访问控制

这种方法看起来很自然,因为否则有人可以通过直接调用服务来绕过访问控制。问题是后台无法知道用户在特定实体上可以使用哪些操作。因此,无法禁用用户不可用的选项,例如“编辑”按钮。

可以向服务添加其他操作以检索特定实体的授权操作,但似乎我们将处理该服务的多个职责。

在后台实现访问控制

假设服务信任后台应用程序,可以决定在后台实现访问控制。这似乎解决了知道用户可以使用哪些动作的问题。这种方法的主要问题是不再可能执行分页搜索,因为该服务现在将返回匹配的每个实体,而不是匹配的实体以及用户也有权查看的实体。

实施集中式访问控制服务

如果访问控制集中在单个服务中,则每个人都可以使用它来查询特定实体的访问权限。但是,我们将无法使用域模型来实施访问控制规则。此方法也存在性能问题,因为为了返回仅包含授权结果的搜索结果列表,无法使用访问控制规则过滤数据库查询。在检索所有搜索结果后,必须在内存中执行过滤

结论

我现在被卡住了,因为上述解决方案都不令人满意。还有什么其他方法可以解决这个问题?有办法解决我提出的方法的局限性吗?

3 个答案:

答案 0 :(得分:1)

  

可以向服务添加其他操作以检索   对特定实体的授权行动,但似乎我们愿意   处理服务的多重责任。

不是真的。从Web服务返回一个标志字段/属性,用于每个记录/对象,然后可以根据用户可以执行的操作来调整UI。这些标志基于与服务正在访问的访问控制相同的信息。这也使该服务能够支持基于浏览器的AJAX访问方法,并在未来跳过后台部分以增加灵活性。

答案 1 :(得分:1)

区分访问控制系统的组件,并在每个有意义的地方实施。

访问列表中的特定搜索结果应由读取结果的服务实现,用户界面永远不需要知道用户无权访问的结果。如果用户可以或可以不以其他方式编辑或与用户被允许看到的数据交互,则服务应该返回具有指示用户可以做什么的标志的数据,并且用户界面应该反映那些标志。实现这些交互的服务应该信任用户界面,它应该在调用服务时验证用户是否具有访问权限。您可能必须在多个数据库查询中实现访问控制逻辑。

用户可能或可能无法访问独立数据的一般功能的访问权应再次由实现该功能的服务控制。该服务应该通过一个也作为服务公开的模块来计算访问权限,以便UI可以尊重访问规则而不是尝试调用用户无权访问的服务。

答案 2 :(得分:1)

我知道我的回答很晚 - 迟到了3年。值得为一个古老的问题揭开新的视角。早在2011年,并不像今天那样成熟。特别是,有一个新模型以及标准实施,可以实现集中授权。

在OP的问题中,OP编写了以下重新集中访问控制:

  

实施集中式访问控制服务

     

如果访问控制集中在单个服务中,则每个人都可以使用它来查询特定实体的访问权限。但是,我们将无法使用域模型来实施访问控制规则。此方法也存在性能问题,因为为了返回仅包含授权结果的搜索结果列表,无法使用访问控制规则过滤数据库查询。在检索所有搜索结果后,必须在内存中执行过滤

OP提到的缺点可能在本土访问控制系统,RBAC或ACL中都是如此。但在中它们已不再适用。让我们一个接一个。

使用域模型实现访问控制规则的能力

使用基于属性的访问控制()和可扩展访问控制标记语言(),可以使用域模型及其属性(或属性)来编写访问控制政策。例如,如果用例是希望查看医疗记录的医生,则域模型将定义Doctor实体及其属性(位置,单位等)以及{{1} } 实体。 XACML中的规则可能如下所示:

  • 当且仅当doctor.location == medicalRecord.location时,具有角色==医生的用户可以对类型==医疗记录的对象执行操作==查看。
  • 当且仅当doctor.id == medicalRecord.assignedDoctor.id
  • 时,具有角色==医生的用户可以对类型==医疗记录的对象执行操作==编辑

XACML的主要优势之一就是密切反映应用程序的业务逻辑和域模型。

性能问题 - 从db

过滤项目的能力

过去,确实无法创建过滤器表达式。这意味着,正如OP指出的那样,人们必须首先检索所有数据然后过滤数据。那将是一项昂贵的任务。现在,使用XACML,可以实现反向查询。运行反向查询的能力是创建一个类型的问题" Alice可以查看哪些医疗记录?" 而不是传统的二元问题"爱丽丝可以查看医疗记录#123吗?" 。 反向查询的响应是一个过滤条件,可以将其转换为SQL语句,例如在此方案中Medical Record,当然假设医生位于芝加哥。

架构是什么样的?

集中式访问控制服务(也称为外部授权)的一个主要优点是,您可以将相同的一致授权逻辑应用于表示层,业务层,API,Web服务甚至数据库。

The XACML any-depth architecture according to Axiomatics