【问题标题】:Access Control in a Web ApplicationWeb 应用程序中的访问控制
【发布时间】:2018-08-18 13:11:27
【问题描述】:

我目前正在阅读很多关于可用于保护应用程序或 Web 应用程序中的资源的访问控制可能性/机制。有 ACL、RBAC、ABAC 和许多其他概念。

假设我开发了一个简单的 Web 服务,它可以在“/api/article”之类的路径上返回知识库文章。 “控制器”连接到数据库并获取所有文章并将它们作为 XML 或 JSON 返回。

现在我想控制哪些用户或组可以访问数据库中的哪些文章。因此,例如,如果用户 'peter' 使用他的凭据访问路由 '/api/article',则 web 服务将只返回对 'peter' 可见的文章。

我想使用 ACL 来控制每个用户/组可以读取/写入/删除的内容。但是我不太明白:

在哪里实施访问控制?如果用户访问路由'/api/articles',我是否只获取控制器中的所有记录并根据访问控制列表检查每条记录(这听起来不是很好的性能明智)?或者有没有办法让数据库的“SELECT”语句只返回该特定用户实际可以看到的记录?

我真的很努力地寻找有关该主题的更多信息,并且有很多关于不同访问控制机制的信息,但没有关于实际执行发生的地点和方式......如果涉及到其他内容,它甚至会变得更加复杂修改、删除等操作...

【问题讨论】:

    标签: security acl software-design access-control


    【解决方案1】:

    这实际上是一个实施问题,每个人都按照自己的方式去做。它还取决于数据的性质,特别是您的授权大小(您是否有 5 个角色并且用户是否附加到他们,或者每个用户是否有一组他可以访问的特定文章,每个用户都不同 - 例如)

    如果您不想在控制器上进行处理,您可以将授权信息存储在数据库中、将用户链接到一组知识库文章或角色的表中(然后将反映在文章)。在这种情况下,您的 SELECT 查询只会传递经过身份验证的用户 ID。这就要求关系的维护是由数据库来完成的,这可能不是很明显。

    或者,您可以将 ACL 存储在控制器上并从那里构建查询 - 针对特定文章或文章组。

    获取所有文章并在控制器上检查它们不是一个好主意(正如您所提到的),DB 的设计也是为了避免此类问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-07-06
      • 1970-01-01
      • 2015-08-24
      • 2016-07-18
      • 1970-01-01
      • 2016-04-08
      • 2018-08-12
      相关资源
      最近更新 更多