q里的权限系l要区分2个概念:
_粒度:表示c(modelQ别U,即仅考虑对象的类?SPAN lang=EN-US>(the type of object)Q不考虑对象的某个特定的实例。比如,对合同这个类?SPAN lang=EN-US>(contract)的管理中Q创建、删除等操作Q对所有的用户都一视同仁,q不区分具体的对象实例(销售合同,生合同Q?/FONT>
l粒度:表示实例(instance)U别Q即需要考虑具体对象的实?/SPAN>(the instance of object)Q当Ӟl粒度是在考虑_粒度的对象cd之后才再考虑特定实例。比如,销售合同管理中Q合同所有者拥有查看、修攏V删除等权限Q其他用户只有合同的查看权限?/SPAN>
权限pȝ的设计原则:权限逻辑配合业务逻辑。即权限pȝ以ؓ业务逻辑提供服务为目标?/SPAN>
l粒度的权限问题因ؓ其业务相x而不具通用意义Q它们被理解为是?/FONT>业务逻辑?/FONT>的一部分。比如,要求Q?/SPAN>?/FONT>某个合同只能被它的创删除,与创同l的用户可以修改Q所有的用户能够览?/FONT>。这既是一个细_度的权限问题,也是一个业务逻辑问题。在q里它是业务逻辑问题Q在整个权限pȝ的架构设计之中不予考虑。当Ӟ权限pȝ的构架设计也必须要能支持q样的业务逻辑。或者说Q系l提供够多但不是完全的控制能力。即Q设计原则归lؓQ?/SPAN>?/FONT>pȝ只提供粗_度的权限,l粒度的权限被认为是业务逻辑的职?/SPAN>?/FONT>?/SPAN>
权限逻辑 ßà _粒?/FONT>
业务逻辑 ßà l粒?/FONT>
概念Q?/FONT>
Object: 指系l中各种功能模块Q业务模型(ModelQ,业务对象(Object)Q界面元素等Q它是主体能讉K到的所有对象。由于对象的cd不同Q被讉K的权限也不同?/SPAN>
Q?Q?SPAN style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal" times="" new="" roman=""> pȝ功能模块Q系l中除了公用的界面,公用的模块外Q其他均Z务功能模块,业务操作在设计阶D完成,因此不存在实例的概念。可以直接针对角色进行授权?/SPAN>
Q?Q?SPAN style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal" times="" new="" roman=""> 界面元素Q除了功能菜单受到控制外Q如要控制功能模块的界面元素其功能模块界面元素也需定义Q大部分界面元素均包含有相关的业务功能操作,因此可以与数据模型统一来处理?/SPAN>
Q?Q?SPAN style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal" times="" new="" roman=""> 业务模型Q业务对象:业务模型是我们的Domain ModelQ开发h员在设计开发阶D就已经定义好了相关的业务操作,也就是相应的权限?/SPAN> 业务对象是我们业务模型的实例?/SPAN>Domain Object。是用户在系l运行时创徏的,因此它的权限也是用户在系l运行时创徏的?/SPAN>
_粒?/FONT> |
|
l粒?/FONT> |
|
Domain Model |
业务模型Q比如合同(Contract ModelQ?/SPAN> |
Domain Object |
业务模型的某个实例话对象Q比如销售合同(Sell Contract ObjectQ?/SPAN> |
Privilege(Operative, Permission) : ?/SPAN>Object Related的操作。就是指Q这个权限是l定在特定的对象上的。比如说部门新闻的发布权限,叫做"部门新闻发布权限"。这p明,?/SPAN>Privilege是一个发布权限,而且是针寚w门新闻这U资源的一U发布权限。权限,包括pȝ定义权限和用戯定义权限Q用戯定义权限之间可以指定排斥和包含关p?/SPAN>(如:dQ修改,理三个权限Q管?/SPAN> 权限 包含 前两U权?/SPAN>)?/SPAN>
Role: 是权限的集合Q是_粒度和l粒?/SPAN>(业务逻辑)的接口。一个基于粗_度控制的权限框架YӞ对外的接口应该是RoleQ具体业务实现可以直接承或拓展丰富Role的内容,Role不是如同User?/SPAN>Group的具体实体,它是接口概念Q抽象的通称?/SPAN>Role的扉K过Group来体玎ͼ所以不考虑Role的承关pR但?/SPAN>Role可以与相关的Group相关联,便于授权?/SPAN>
Group: 用户l,权限分配的单位与载体Q直接映组l关pR权限不考虑分配l特定的用户。组可以包括l?/SPAN>(以实现权限的l承)。组可以包含用户Q组内用L承组的权限?/SPAN>Group要实现ѝ即在创建时必须要指定该Group?/SPAN>Parent是什?/SPAN>Group。在_粒度控制上Q可以认为,只要某用L接或者间接的属于某个Group那么它就具备q个Group的所有操作许可。细_度控制上,在业务逻辑的判断中Q?/SPAN>User仅应x其直接属于的GroupQ用来判断是?/SPAN>?/FONT>同组??/SPAN>
但是Group的承导致的权限l承和组l关pL好相反,l织关系的上层相应的权限更大Q所以是一U逆向l承?/SPAN>
User: Ua的用P与权?/SPAN>(operative?permission?privilege)分离,只能通过Roled联相应的权限?/SPAN>
关系Q?/FONT>
Privilege ß n : 1 à Resource
Role ß n : n à Privilege
Group ß n : n à User
Group ß n : n à Role
User ß n : n à Role
权限pȝ的操作模式:
(1): 创造资源,权限: q里要从_,l粒?/SPAN>2斚w来考虑
_粒度:开发h员设?/SPAN>DomainModel的时候就定义好相关的操作。比?/SPAN>ContractModel
q个DomainModel,开发h员设计的时候就已经定义好了模型的相x作,比如查看Q修改等{。默认的情况下对所有的Role都是相同的?/SPAN>
l粒度: 用户创徏一?/SPAN>DomainModel的实?/SPAN>DomainObject的时候指定相关的?/SPAN>
限以及权限分配。比如销售合同只能创有修改的权限,?/SPAN>Group的h员只能拥有查看的权限?/SPAN>
(2): 分配权限: Administrator指定相关DomainModel的权限分?/SPAN>,创徏RoleQ创?/SPAN>GroupQ给
Group分配UserQ给Group赋予某个Role{等?/SPAN>
(3): 使用权限: User 使用 Administrator分配的角色去使用相应的系l功能?/SPAN>
模块划分Q?/FONT>
1) 对象理模块。此模块主要负责从粗l粒度对于系l中可提供的资源或资源实例进行管理?/SPAN>
2) 权限理模块。此模块主要负责对资源权限进行管理。管理员可以在粗l粒度下对资源权限进行管理。用户可以对创徏的资源实例进行权限的理?/SPAN>
3) 角色理模块。此模块主要负责对角色进行相应的理Q包括添加、删除、修改)Q对角色所拥有的权限进行相应的理Q包括授予、删除所拥有的权限)Q对用户和组赋予相应的角色等{?/SPAN>
4) 用户理模块。此模块主要负责对用戯行管理(包括d、删除、修改)Q对用户所属的角色q行理Q包括添加、删除)Q对用户所属的l进行管理?/SPAN>
5) l管理模块。组映射l织机构Q提供对于部门组l机构维?/SPAN>(d、修攏V删?/SPAN>)Q对l的成员q行l护Q对l所拥有的角色进行管理?/SPAN>