下面是用户,角色和项目的表定义:
CREATE TABLE users
(
id serial NOT NULL PRIMARY KEY,
username character varying UNIQUE,
password character varying,
first_name character varying,
last_name character varying,
...
);
CREATE TABLE roles
(
id serial NOT NULL PRIMARY KEY,
name character varying NOT NULL,
description character varying,
...
);
CREATE TABLE element_1
(
id serial NOT NULL PRIMARY KEY,
name character varying NOT NULL,
description character varying,
...
);
...
现在我有了两种设计权利的方式。一个具有权限类型列的表或10个权限表-我要控制对每个元素的访问权限的表。
一个权限表与每个元素一个权限表的优缺点是什么? -还是更合适的方法?
#1 楼
首先,您打算实施哪种类型的安全模型?基于角色的访问控制(RBAC)或自由访问控制(DAC)?基于角色的访问控制(RBAC)模型中的RBAC,对资源的访问
基于分配给用户的角色。
在此模型中,管理员
将用户分配给具有
预定权限和
特权的角色。由于用户与角色的关联,用户
可以访问某些资源并执行特定任务。 RBAC也被称为“非随意访问”控件。分配给用户的角色
是集中管理的。
DAC在自由访问控制(DAC)模型中,对
资源的访问基于用户的身份。 br />通过将用户置于与
资源关联的访问权限
控制列表(ACL)上,可以授予该用户对
资源的权限。资源的ACL
上的条目称为访问控制条目
(ACE)。当用户(或组)是DAC模型中对象的
所有者时,
,该用户可以将权限授予其他
用户和组。 DAC模型是基于资源所有权的。
请参见源代码
1)在RBAC中:您需要ElementType表来为角色分配权限(用户被分配给角色)。 RBAC定义:“此角色/用户可以做什么”。管理员为角色分配权限,并为角色分配权限,向用户分配角色以访问资源。
2)在DAC中:用户和角色通过访问控制列表(所有权)对元素具有权限。 DAC定义:“谁有权访问我的数据”。用户(所有者)向拥有的资源授予权限。
我以任何方式建议此数据模型:
CREATE TABLE ElementType
(
Id (PK)
Name
...
)
CREATE TABLE ElementBase
(
Id (PK)
Type (FK to ElementType)
...
)
(一对一关系)
CREATE TABLE Element_A
(
Id (PK, FK to ElementBase)
...
)
CREATE TABLE Element_B
(
Id (PK, FK to ElementBase)
...
)
1)RBAC(多对多关系)
CREATE TABLE ElementType_To_Role_Rights
(
RightId (PK)
RoleId (FK to Role)
ElementTypeId (FK to ElementType)
...
)
2)DAC(多对许多关系)
CREATE TABLE ElementBase_To_Actor_Rights
(
RightId (PK)
ElementBaseId (FK to ElementBase)
ActorId (FK to Actor)
...
)
CREATE TABLE Actor
(
Id (PK)
Name
)
CREATE TABLE User
(
Id (PK, FK to Actor)
Password
...
)
CREATE TABLE Role
(
Id (PK, FK to Actor)
...
)
评论
使不相关的Element_xxx实体从ElementBase派生是个好主意吗?例如,我需要跟踪我的产品和客户的访问控制。您是否建议我创建一个通用ElementBase并让element_base_id作为product_id和customer_id的主键,即使它们不相关?
–Parth Shah
2015年6月4日在7:22
RBAC与DAC,+ 1
–尔凡
16 Dec 6'在5:20
@ParthShah您采取什么方法解决问题?
– Vivek Vardhan
17年11月17日在7:51
#2 楼
对于每个元素都有一个权限表,一旦添加元素,就需要添加一个表。这将增加应用程序维护。将所有内容放在一个表中的缺点是您可能会遇到扩展问题,但是可以使用分区,实例化视图和/或虚拟列来缓解这些问题。可能没有必要采取此类措施。
就表设计而言,如果这是在Oracle上,我可能会提出这样的建议:
CREATE SEQUENCE UserRoleID;
CREATE TABLE USERROLE
(
USERID NUMBER(7) NOT NULL
, ROLEID NUMBER(7) NOT NULL
, CONSTRAINT USERROLE_PK PRIMARY KEY
(
USERID
, ROLEID
)
ENABLE
)
ORGANIZATION INDEX;
CREATE TABLE PERMISSIONS
(
ID NUMBER(7) NOT NULL
, ELEMENTID NUMBER(7) NOT NULL
, CONSTRAINT USERROLE_PK PRIMARY KEY
(
ID
, ELEMENTID
)
ENABLE
)
ORGANIZATION INDEX;
程序包代码可以使用UserRoleID序列,用于根据需要填充“用户”表中的ID和“角色”表中的ID。然后,权限表可以将
元素分配给角色,这些元素又分配给用户和/或将元素直接分配给
。
评论
您是否看到过执行此操作的ASP.NET用户数据库? (据我了解您的要求,我可能是错的)