权限方案设计方案分析与设计 No.1
2010-10-26 11:24 Creative dream 阅读(912) 评论(4) 编辑 收藏 举报最近接手公司信息化建设，在网上也看了很资料，对权限的设计也是仁者见仁，智者见智了，我这里写了一篇说明书，希望对大家有所帮助，不对的地方还望各位IT界朋友多多指正。
企业信息化权限方案设计说明书
1 摘要
权限设计是每一个系统的重要组成部分，主要用于控制功能和流程，以满足不同系统用户的需求，提高系统安全性，成为应用系统不可缺少的一部分，而设计一个相对通用的权限系统更具有很大意义。
本文将列举目前几种常见的权限设计方案，对比其优势、劣势，结合企业信息化需求，设计合适地权限方案。
2 需求说明
2.1 不同职责的人，对于系统操作的权限应该是不同的。
2.2 可以以“组”的形式对权限进行分配。
对于一个业务比较繁多的企业信息化平台来说，如果要求管理员为员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中应以“组”的形式对权限进行分配，将权限一致的人员编入同一组，然后对该组进行权限分配。
2.3 权限管理系统应该是可扩展的。
要求权限的设计可以加入到任何带有权限管理功能的系统中。就像组件一样可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
2.4 满足业务系统中的功能权限。
在业务系统中，存在着两种权限管理，一种是功能权限的管理，另一种则是资源权限的管理，在不同系统组件之间，功能权限是可重用的，而资源权限则不能。
3 定义
CRUD：分别指Create创建、Read读取、Update更新、Delete删除。
RBAC(Role-Based Access Control)：基于角色的访问控制。
4 环境
开发工具：Microsoft Visual Studio 2010 EN
开发语言：C#
开发模型：ADO.Net Entity Framework
5 常见权限
5.1 等级权限方案
在这种系统中，权限级别如同官阶从低到高排列，每个用户拥有一个权限，其中设定了这个用户的权限等级，在用户需要执行操作前先查看其权限等级是否大于执行操作所需要的权限等级，是则进行操作。
这种权限方案在论坛中很常见，用户类基本属性如下：
Id // 用户ID
Name // 用户名
权限类基本属性如下：
Id // 权限ID
UserId // 权限对应用户ID
Level // 用户权限等级
权限可执行功能如下：
0 访问
1 可跟帖
2 可创建主帖
3 可删除主帖
4 可创建频道
5 可删除频道
6 可查看用户
7 可分配用户权限
8 可修改用户密码
9 可删除用户
……
使用的时候，获取用户对应操作的权限等级与权限等表进行比较，高于目标权限等级即可进行当前操作，否则抛出权限不够。
以上等级权限适用于小型项目开发，而且需求较为单一者，同样权限等级也较少，如果每一个用户对应多个模块，每一个模块都具有相同的权限分配，就需要对以上权限方案进行更改，在权限类中增加模块编号，才能进行正常判断，可见此权限分配方案使用起来简单，但却有最致命的一点，那就是扩展性太差，灵活性不高，不适用于大型项目开发以及逻辑比较复杂的业务。
5.2 单纯用户等级权限方案
这种权限分配在大多数小型办公软件中常用，目前也在很多场合使用，系统定义多个用户等级，如“超级管理员”、“普通管理员”、“匿名用户”，为每一个用户等级分配不同的权限，每一个用户对应一个用户等级，程序启动时根据登录用户的等级对窗体进行配置，对没有权限的菜单设置为隐藏或不可用。
这种权限分配用户类基本属性如下：
Id // 用户ID
Name // 用户名
用户等级类基本属性如下：
Id // 用户等级ID
Name // 用户等级名称
UserId // 用户ID
权限类基本属性如下：
Id // 权限编号
UserLevelId // 用户等级ID
用户可执行操作均在权限类中定义，在程序中对每一个权限操作进行判断，如果所属用户等级中包含此权限，可进行当前操作，否则抛出没有当前操作权限。
这种权限方案可以解决中小型业务需求，对于业务繁杂的企业信息平台，其不致命之处依然是可扩展性太差，灵活性不高，对于不同模块仍需要重新定义权限类，一方面造成用户等级的分配臃肿，每一个权限对应CRUD也无法细分。
5.3 基于RBAC动态权限分配
RBAC的核心思想是把访问权限赋给角色而不是用户，用户通过它所属的角色来获得访问权限，具有更强的灵活性和更广泛的适用性。它主要引入了角色这一概念，角色的实质是一个或一群用户在组织内可执行的操作的集合。在RBAC内,角色为访问控制的主体，角色决定了用户对资源所拥有的权限以及可以执行的操作，其中访问控制策略在RBAC中主要体现为用户/角色、角色/权限和角色/角色之间的关系。
RBAC具有如下特点:
1、 授权管理灵活；
2、 授权管理机制更加接近实际､更加社会化；
3、 用户､角色和权限是多对多的关系；
4、 系统的操作用户与数据对象没有直接的联系｡
本文正是采用此种权限分配方案，并结合企业信息化需求设计，参考Membership机制去除对于分组的控制。
具体设计模型（ADO.NET entity framework）如下：
1、数据字典：
Module：模块组件类
Id：编号
Name：名称
Description：描述
Cover：封面（用于显示用）
LimitGroup：权限分组
Id：编号
Name：名称
Description：描述
ModuleId：模块编号
Limit：所有权限
Id：编号
Name：名称
Description：描述
LimitGroupId：权限分组编号
Action：权限所对应的操作（CRUD）
Id：编号
Name：名称
Description：描述
2、权限操作部分
字段较多，纯属劳动性工作，看英文便知意思，不对字段做解释了，
Member：成员信息（用于登录）
Role：角色
OrganizationId：组织机构编号，对应Organization表，用于角色可以访问的数据。
RoleModule：角色-模块
RoleLimit：角色-权限（把所有权限统一存储，没涉及权限分组）
RoleLimitAction：角色-权限-动作
Organization：组织机构
