访问控制:RBAC具有其他组成员身份而不是对象属性

时间:2017-02-12 14:23:42

标签: mysql permissions authorization rbac abac

给定一个应用程序根据某些用户权限显示对象(例如电影)。

显示或创建对象的常规权限实现为具有角色和权限的RBAC。

访问具有某些属性的对象的特定权限(例如具有“戏剧”属性的电影)应该使用成员资格来实现。这意味着该对象没有属性“戏剧”,它是“戏剧”组的成员。如果用户和对象是同一组中的成员,则用户具有访问此对象的特定权限。可以有不同的组来显示,创建或删除对象,如简单的查看器组或某种编辑器组。此外,还有一个表,指定哪些组类型与某些对象的某些操作相关。例如,对象“电影”上的动作“显示”的相关组可以是“类型”和“年龄”(电影适合某些观众)。

以所描述的方式实现它的原因是在不触及代码的情况下具有很大的灵活性。可以在数据库中处理对组的更改。

通用数据库设计:

design

示例:电影“The Revenant”是“流派:戏剧”和“年龄:18”的成员。如果用户也是这些组的成员,则用户可以访问它。

example

这听起来像是一个好方法吗?是否存在与此方法类似的现有解决方案?它是否有重大缺点(例如,数据库查询太多 - 每天可能有几百个用户)?

请与我分享您对此问题的看法 - 选择“戏剧”作为示例的类别并非巧合;)我只是不知道这是不是死路一条,还是我正朝着正确的方向前进。我坚持了很长一段时间。

1 个答案:

答案 0 :(得分:0)

至少你有一种很好的幽默感: - )

你的方法听起来不错。只要保持参数数量较少,就可以摆脱基于角色的访问控制(RBAC)和一些其他参数,例如:小组成员。

但从长远来看,如果你想实现业务驱动的授权(访问控制),你需要一种独立于你的代码的方法:你不想重写你的应用程序每当需求发生变化时都会编码。

为此,有一种称为基于属性的访问控制(ABAC)的访问控制模型,可让您独立于代码定义授权策略。

在ABAC中,您有以下概念:

  • 定义策略执行点(PEP)和策略决策点(PDP)的体系结构。 PEP位于您的应用程序前面(或内部)。它拦截业务请求(例如,查看电影的请求)并向PDP发送授权请求。 PDP配置有策略。根据请求,PDP将做出决定:是,允许或否,拒绝。
  • 策略语言:策略语言是基于属性的(因此名称为ABAC)。这意味着您可以使用任意数量的属性(例如,用户角色,用户ID,用户组成员身份,还有用户年龄,用户位置,用户订阅以及资源属性,如电影评级,电影类别,电影价格...... )
  • 请求/响应方案:这是您要求授权的方式。它本质上是一个是/否流。 "用户可以做X吗?","是的他们可以。"

ABAC有几种实现方式 - 其中一些是特定于框架的,例如CanCanCan。 XACML和ALFA是两种与任何特定框架无关的方法。您可以选择任何一种语言的开源和商业实现,例如:

  • 开源:SunXACML,ATT XACML
  • 商业:Axiomatics Policy Server