【问题标题】:Permissions design pattern that allows date-based access允许基于日期访问的权限设计模式
【发布时间】:2014-06-08 06:34:47
【问题描述】:

我正在寻找在我的应用中实现授权(而非身份验证)方案的方法。

系统中目前有两个角色:A 和 B,但可能还有更多。用户只有一个角色。

基本上,我现在设置的是两个数据库表。一种是针对模型的基于角色的权限,另一种是针对特定用户的权限。我在想这样,用户可以根据他们基于角色的权限拥有一组默认权限,但他们也可以授予/撤销特定的权限。

例如:

table: user_permissions
columns:
    user_id: [int]
    action: [string]
    allowed: [boolean]
    model_id: [int]
    model_type: [string]

table: role_permissions
columns:
    role: [int]
    action: [string]
    model_type: [string]        

user_permissions 表中,allowed 字段指定是否允许该操作,如果该值为 0,则可以撤销权限。

在另一个表中,我有每个动作的定义:

table: model_actions
columns:
    action: [string]
    bitvalue: [int]
    model_type: [string]

我这样做是为了当我检查模型的权限时,例如 ['create', 'delete'],我可以使用按位和运算来比较用户的权限和我正在检查的权限。例如,模型 X 可能具有以下模型操作:

action: 'create'
bitvalue: 4
model_type: X

action: 'delete'
bitvalue: 2
model_type: X

action: 'view'
bitvalue: 1
model_type: X

如果我的用户/角色权限指定模型 X 的创建、查看和删除操作分别为 1、0 和 1,则根据 model_actions 表将其表示为 110。当我检查是否可以创建模型X时,我使用create为4这个事实来构造bitarray 100。如果110和100的按位与运算为100,则权限有效。

无论如何,我想我已经找到了一个细粒度的权限设计模式。如果不是,请随时对我进行相关教育。

我的问题的实际焦点涉及以下内容:

我的一些模型具有与时间相关的操作。例如,您只能在模型 Y 的 created_at 日期后不超过 24 小时内删除它。

我的想法是在创建模型时自动创建一个 cron 作业,该作业将在发生这种情况的日期更新权限。对于模型 Y,我想在 user_permissions 中插入一条记录,以撤销该模型的“删除”操作。

我的问题是:这是可取的吗?

编辑

如果我在 SQL 表中包含另一行,它指定了“翻转”(flipDate) 权限的日期,该怎么办?如果定义了翻转日期,并且如果当前日期在翻转日期之后,则权限被撤销。这似乎比一系列 cron 作业更容易管理,尤其是在模型可能会更新时。

【问题讨论】:

    标签: permissions authorization role-base-authorization


    【解决方案1】:

    您的模型看起来不错,但是...您正在重新发明轮子,并且正如您自己意识到的那样,您的模型不够灵活,无法满足其他参数,例如时间。

    在授权的历史上,有一种传统的、广为接受的模型,称为基于角色的访问控制 (RBAC)。当您有一组明确定义的角色以及这些角色之间的层次结构时,该模型非常有效。

    但是,当层次结构不清晰或存在关系(例如医患关系)或存在动态属性(例如时间、位置、IP...)时,RBAC 不起作用好。几年前出现了一种新模型,称为基于属性的访问控制 (ABAC)。在某种程度上,它是 RBAC 的演变或概括。使用 ABAC,您可以根据属性定义授权逻辑。属性是一组描述用户、操作、资源和上下文的键值对。使用属性,您可以描述任意数量的授权情况,例如:

    • 当且仅当患者被分配给该医生时,医生才能在上午 9 点到下午 5 点之间查看患者的病历
    • 当且仅当患者与护士属于同一诊所时,护士才能编辑患者的病历。

    ABAC 可以实现所谓的 PBAC 或基于策略的访问控制,因为现在授权逻辑从专有代码和数据库方案转移到一组集中管理的策略中。这些策略的实际标准是 XACML,即可扩展访问控制标记语言。

    简而言之,XACML 让您能够以一种技术中立的方式、以一种解耦、外部化的方式来做您正在寻找的事情。这意味着,您可以定义一次授权并在任何重要的地方强制执行。

    我建议您查看有关该主题的这些优秀资源:

    【讨论】:

    • 实际上,.. 这个答案值得奖励,因为它指向了已经存在的解决方案。而且,它也让我意识到,授权可以集成到域,但可以与域分离。因为,授权可以(可选地)对域模型进行操作,它也可以忽略模型。而且,接口(端口和适配器模式)实现会定义权限,域实现不依赖于授权,但是可以稍后开发复杂的授权实现,或者可以使用一些外部系统来实现授权。
    • 谢谢,非常感谢
    猜你喜欢
    • 2014-11-22
    • 1970-01-01
    • 2011-10-02
    • 2014-08-13
    • 1970-01-01
    • 2018-04-02
    • 1970-01-01
    • 2011-08-15
    • 2020-05-29
    相关资源
    最近更新 更多