如何跨多个应用程序实施授权策略？
背景
我有一个后台办公室，负责管理来自各种来源的信息。部分信息位于后台可以直接访问的数据库中，部分信息通过访问Web服务进行管理。此类服务通常提供 CRUD 操作以及分页搜索。
有一个访问控制系统可以确定允许用户执行哪些操作。用户是否可以执行某些操作的决策是由依赖于底层数据模型的授权规则定义的。例如，有一条规则允许用户编辑资源（如果她是该资源的所有者），其中所有者是资源表中的一列。还有其他规则，例如“如果资源属于某个组织并且用户是该组织的成员，则用户可以编辑该资源”。 当域模型可直接用于访问控制系统时，此方法效果很好。它的主要优点是避免复制领域模型中已经存在的信息。
当要操作的数据来自 Web 服务时，这种方法就会开始引起问题。我可以看到下面将讨论的各种方法。
在服务中实现访问控制
这种方法看起来很自然，因为否则有人可以通过直接调用服务来绕过访问控制。问题在于后台无法知道用户可以在特定实体上执行哪些操作。因此，无法禁用用户不可用的选项，例如“编辑”按钮。
人们可以向服务添加额外的操作来检索特定实体上的授权操作，但似乎我们将处理该服务的多项职责。
在后台实施访问控制
假设服务信任后台应用程序，则可以决定在后台实施访问控制。这似乎解决了了解用户可以执行哪些操作的问题。此方法的主要问题是不再可能执行分页搜索，因为服务现在将返回每个匹配的实体，而不是匹配且用户也有权查看的实体。
实施集中式访问控制服务
如果访问控制集中在单个服务中，那么每个人都可以使用它来咨询特定实体的访问权限。但是，我们将失去使用域模型来实现访问控制规则的能力。这种方法还存在性能问题，因为为了返回仅包含授权结果的搜索结果列表，无法使用访问控制规则过滤数据库查询。必须检索所有搜索结果后在内存中执行过滤。
结论
我现在陷入困境，因为上述解决方案都不令人满意。还可以使用哪些其他方法来解决这个问题？有没有办法解决我提出的方法的局限性？
Background
I have a backoffice that manages information from various sources. Part of the information is in a database that the backoffice can access directly, and part of it is managed by accessing web services. Such services usually provides CRUD operations plus paged searches.
There is an access control system that determines what actions a user is allowed to perform. The decision of whether the user can perform some action is defined by authorization rules that depend on the underlying data model. E.g. there is a rule that allows a user to edit a resource if she is the owner of that resource, where the owner is a column in the resources table. There are other rules such as "a user can edit a resource if that resource belongs to an organization and the user is a member of that organization".
This approach works well when the domain model is directly available to the access control system. Its main advantage is that it avoids replicating information that is already present in the domain model.
When the data to be manipulated comes from a Web service, this approach starts causing problems. I can see various approaches that I will discuss below.
Implementing the access control in the service
This approach seems natural, because otherwise someone could bypass access control by calling the service directly. The problem is that the backoffice has no way to know what actions are available to the user on a particular entity. Because of that, it is not possible to disable options that are unavailable to the user, such as an "edit" button.
One could add additional operations to the service to retrieve the authorized actions on a particular entity, but it seems that we would be handling multiple responsibilities to the service.
Implementing the access control in the backoffice
Assuming that the service trusts the backoffice application, one could decide to implement the access control in the backoffice. This seems to solve the issue of knowing which actions are available to the user. The main issue with this approach is that it is no longer possible to perform paged searches because the service will now return every entity that matches, instead of entities that match and that the user is also authorized to see.
Implementing a centralized access control service
If access control was centralized in a single service, everybody would be able to use it to consult access rights on specific entities. However, we would lose the ability to use the domain model to implement the access control rules. There is also a performance issue with this approach, because in order to return lists of search results that contain only the authorized results, there is no way to filter the database query with the access control rules. One has to perform the filtering in memory after retrieving all of the search results.
Conclusion
I am now stuck because none of the above solutions is satisfactory. What other approaches can be used to solve this problem? Are there ways to work around the limitations of the approaches I proposed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
并不真地。从 Web 服务为每个记录/对象返回一个标志字段/属性，然后可以根据用户可以执行的操作来美化 UI。这些标志基于用于服务正在访问的访问控制的相同信息。这也使得该服务能够支持基于浏览器的 AJAX 访问方法，并在未来跳过后台部分以增加灵活性。
Not really. Return a flags field/property from the web service for each record/object that can then be used to pretty up the UI based on what the user can do. The flags are based off the same information that is used for access control that the service is accessing anyway. This also makes the service able to support a browser based AJAX access method and skip the backoffice part in the future for added flexibility.
区分访问控制系统的组件并在有意义的地方实施每个组件。
对列表中特定搜索结果的访问应该由读取结果的服务来实现，并且用户界面永远不需要知道用户无权访问的结果。如果用户可能或可能不以其他方式编辑或交互允许用户查看的数据，则服务应返回该数据，并带有指示用户可以执行的操作的标志，并且用户界面应反映这些标志。实现这些交互的服务不应该不信任用户界面，它应该在调用服务时验证用户是否具有访问权限。您可能必须在多个数据库查询中实现访问控制逻辑。
用户可能有权或可能无权访问独立数据的一般功能的访问应再次由实现该功能的服务控制。该服务应通过也作为服务公开的模块来计算访问权限，以便 UI 可以遵守访问规则，而不是尝试调用用户无权访问的服务。
Distinguish between the components of your access control system and implement each where it makes sense.
Access to specific search results in a list should be implemented by the service that reads the results, and the user interface never needs to know about the results the user doesn't have access to. If the user may or may not edit or interact in other ways with data the user is allowed to see, the service should return that data with flags indicating what the user may do, and the user interface should reflect those flags. Service implementing those interactions should not trust the user interface, it should validate the user has access when the service is called. You may have to implement the access control logic in multiple database queries.
Access to general functionality the user may or may not have access to independant of data should again be controlled by the service implementing that functionality. That service should compute access through a module that is also exposed as a service so that the UI can respect the access rules and not try to call services the user does not have access to.
我知道我的回复很晚了——晚了三年。值得对一个古老的问题提供一些新的认识。早在 2011 年，访问控制那时并不像今天那么成熟。特别是，有一个新模型，abac通过标准实现，xacml 使集中授权成为可能。
在OP的问题中，OP写了以下重新集中访问控制：
OP 提到的缺点在本地访问控制系统、RBAC 或 ACL 中可能确实存在。但它们在 abac 和 xacml。让我们一一来看。
使用域模型实现访问控制规则的能力
使用基于属性的访问控制 (abac）和可扩展访问控制标记语言（xacml），可以使用域模型及其属性（或属性）来编写访问控制策略。例如，如果用例是希望查看医疗记录的医生，则域模型将定义
Doctor实体及其属性（位置、单位等）以及 <代码>医疗记录实体。 XACML 中的规则可能如下所示：XACML 的主要优点之一是精确镜像密切关注应用程序的业务逻辑和域模型。
性能问题 - 从数据库中过滤项目的能力
在过去，确实不可能创建过滤表达式。正如OP指出的那样，这意味着必须首先检索所有数据，然后过滤数据。那将是一项昂贵的任务。现在，有了XACML，就可以实现反向查询了。运行反向查询的能力是创建“Alice 可以查看哪些医疗记录？”类型的问题，而不是传统的二元问题“Alice 可以查看医疗记录 #123？” 。
反向查询的响应是一个过滤条件，可以转换为 SQL 语句，例如在这种情况下 SELECT id FROM MedicalRecords WHERE location=Chicago ，当然假设医生位于芝加哥。
架构是什么样的？
集中式访问控制服务（也称为外部化授权）的主要优点之一是您可以将相同的一致授权逻辑应用于表示层、业务层、API、Web 服务甚至数据库。
I understand my response is very late - 3 years late. It's worth shedding some new light on an age-old problem. Back in 2011, access-control was not as mature as it is today. In particular, there is a new model, abac along with a standard implementation, xacml which make centralized authorization possible.
In the OP's question, the OP writes the following re centralized access control:
The drawbacks that the OP mentions may have been true in a home-grown access control system, in RBAC, or in ACL. But they are no longer true in abac and xacml. Let's take them one by one.
The ability to use the domain model to implement the access control rules
With attribute-based access control (abac) and the eXtensible Access Control Markup Language (xacml), it is possible to use the domain model and its properties (or attributes) to write access control policies. For instance, if the use case is that of a doctor wishing to view medical records, the domain model would define the
Doctorentity with its properties (location, unit, and so on) as well as theMedical Recordentity. A rule in XACML could look as follows:One of the key benefits of XACML is precisely to mirror closely the business logic and the domain model of your applications.
Performance issue - the ability to filter items from a db
In the past, it was indeed impossible to create filter expressions. This meant that, as the OP points out, one would have to retrieve all the data first and then filter the data. That would be an expensive task. Now, with XACML, it is possible to achieve reverse querying. The ability to run a reverse query is to create a question of the type "What medical record can Alice view?" instead of the traditional binary question "Can Alice view medical records #123?".
The response of a reverse query is a filter condition which can be converted into a SQL statement, for instance in this scenario
SELECT id FROM medicalRecords WHERE location=Chicagoassuming of course that the doctor is based in Chicago.What does the architecture look like?
One of the key benefits of a centralized access control service (also known as externalized authorization) is that you can apply the same consistent authorization logic to your presentation tier, business tier, APIs, web services, and even databases.