数据库权限和角色模型

目录(?)[+]

  管理域

系统安全模型设计

1       修改历史

版本

修改历史

 作者

描述

开发时间(h)

0.1

2007-9-5

LevinSoft

创建文档得基本结构、基本流程

5

0.2

2007-9-26

Levinsoft

优化了系统概念

0.1

0.3

2007-11-14

Levinsoft

丰富介绍内容

增加了安全框架的章节

1

2       介绍

安全永远是Web应用程序必须要面对和解决的头等大事。绝大多数的JavaEE企业级应用程序都有不同成程度的安全需求。通常来说，应用程序都需要保证几个基本的安全需求。首先，应用程序必须能够识别访问者的身份；其次，应用程序必须对Web资源提供安全保证，拒绝未经授权的访问；最后，在多层应用程序的模型中，应用程序还要有能力对业务逻辑组件提供保护，以防止非法用户绕过Web层调用受保护的方法。

安全系统 包括两个明显的问题：认证和授权。认证就是识别用户身份，一个用户通过认证来告诉系统“我是谁”，从而确定用户的身份。认证有多种方式，通常可以使用用户名和口令实现认证，但是，还可以使用数字证书等形式实现更安全的认证。一旦确定了用户的身份，下一步就是要确定用户是否有权进行某种给定的操作，即授权。例如，是否能够在网站首页发布一个文章。

由于用户通常很多，对于每个用户进行授权会非常麻烦。因此基于角色的权限控制（Role Based Access Control, RBAC）就成为一种最流程的授权方式。

对于一个中型或大型的软件系统，安全管理是一个基础模块，涉及到用户、角色、操作权限、菜单、管理域等相关知识和模型，他们分别有自己的职责，同时相互关联，共同构建起安全模型。

建立合理框架模型，能方便管理用户、管理用户权限，保证功能可配置性和安全性， 有利于整个系统的演化。不合理安全模型影响整个软件的使用，也不利于软件的演化。

3       基本概念

3.1    系统

定义一：按一定的关系或功能组成的实体，能够提供一项或一系列的功能。

    定义二：满足一系列目标的相互作用的各个部分的结构化的组合。

按照功能大小的来划分：系统、模块、功能、操作。

对于一个大、中型软件系统通常划分为：系统、子系统、模块、功能、操作。根据功能的大小，可以把系统划分为几个子系统。可以把性质相同或类似的模型划分到一个子系统中；功能通常和菜单相对应；操作通常包括：增、删、改、查、批量增加、批量删除、批量修改、批量导出等。

3.2    用户

指在系统中能使用某些服务或功能的实体。

对于一个电信级别的支撑系统，通常用户类型划分：系统管理员、业务管理员、代理商、服务供应商、企业用户、个人用户等。当前业务平台通常都是按用户类型划分的。

3.3    角色

3.3.1            角色概念

1.    角色是一种抽象的逻辑分组，代表具有同等权限的用户组。

2.    也称“脚色”。戏剧、电影名词。指剧中人物。

3.    “社会角色”的简称。指个人在社会关系位置上的行为模式。它规定一个人活动的特定范围和与人的地位相适应的权利义务与行为规范，是社会对一个处于特定地位的人的行为期待。

故事影片中由演员扮演的人物。一般分为主要角色（简称主角）、次要角色（配角）和群众角色等。

作品中的角色，是指漫画、小说、戏剧或电影等著作中虚构的人物、动物或者其他生物，乃至于机器人。通常来讲，这类角色的首要特征是虚拟性和独创性，其不同于现实生活中体现具体社会关系的真实人物。

4.    在软件系统中，指登陆系统的用户在系统位置上的行为模式。它规定登陆用户的特定的范围和与用户的地位相适应的权利义务与行为规范，是软件系统对一个特定地位的用户的行为的期待。

5.    角色：角色是操作权限的集合，通过将一个或多个角色分配给用户，可以授予用户对系统进行操作的权限。角色有管理域属性，这样可以唯一的定位一个角色的范围。

3.3.2            角色划分

角色的划分方式比较常见的是按用户类型划分和按功能划分。

Ø        按用户类型划分：可以分为系统管理员、业务管理员、代理商、服务供应商、企业用户等。

Ø        按功能划分：可以分为系统管理员、业务管理员、计费管理员、帐务管理员、报表管理员等，

对于一个业务受理系统可以根据不同业务类型来定义不同的角色，例如：业务1角色、业务2角色等，这样的好处就是直观。当开展不同的业务时，就可以建立和分配不同的角色，同时给角色分配不同的权限。

角色可以分级别，设计角色表时，可以采用子关联的方式，增加一个父角色字段。

一个系统，通常要设置超级管理(super system)角色，它是个特殊的角色，有系统最大的权限，通常包括：

1．不需要进行数据权限认证。查看、操作大部分数据。但是出于安全考虑，例如：修改用户账户、修改用户订购情况等，有些条件下，是需要限制的。

2．配置系统关键参数。

3．分配不同角色。

4．给角色分配权限等等。

3.4    用户与角色关系

由于角色一般不多，如一个部门种，角色可以分为管理员、经理、员工等几类，资源和角色关联，每个用户根据自身的角色获得相应的权限，这样可以大大简化了授权的逻辑。比如：对于部门工资系统，每个员工都可以浏览自己的工资信息，但是无权给自己加薪，而经理则可以调整员工工资的权限，管理员具有为新员工创建工资记录、定期备份数据等系统维护的权限。若用户A从员工被提升为经理，则该用户的角色就从员工变成经理，从而获得了经理级别的权限。因此，在基于角色的权限系统中，授权不和用户直接挂钩，而是和角色挂钩，用户再通过角色关联，最终获得相应的授权。

值得注意的是，用户和角色通常不是简单的多对一的关系，有一个用户往往有多个角色，例如：一个操作员被任命为管理员，就具有了员工和管理员这两个角色。3.4   

管理域：是一个虚拟的概念，是区分和过滤用户和数据的关键参数。电信中，不同的区号代表不同的范围，一个区号就可以代表一个域，一个域可以代表多个区号。

但是实际应用中，为了更好的扩展性，可以建立管理域模型，定义一定的标准，可以采用分级的管理模式，可以对物理存在的不同的区号数据进行管理。比如：0 代表省中心域，它可以管理全省的各个区号下的数据， 01 代表某某业务域，可以管理几个区号下的数据。

通过管理域这个虚拟的概念，可以关联几个区号进行管理，在逻辑上，通过域可以把这些物理上不同的区号，进行管理起来。对计费来讲，可以方便的区分订购关系、话单等所属的管理域。

对于一个区号，必须隶属一个域。

域是可以分级别的。可以根据具体项目的大小，分成不同的域。对于一个省级别的项目，一般分成2级：省中心域级别和地市级。全国的可以分成3级，全国级别、省中心级别和地市级。

3.5    权限

1.      操作权限：操作权限是对系统操作的约束，主要针对WEB页面发起的请求，基于URL进行权限过滤。

2.        数据权限：数据权限是指针对特定数据实体的数据行级的操作权限，其中包括：增、删、改、查等操作，每一个操作都对应一个细粒度的数据权限，可以通过给角色分配相应的数据权限，使角色具有该项功能。操作权限一般对应于类中（对于struts，就是action中的方法）的方法。

3.        注册权限：把操作权限插入到权限表中。通常是建立两个表：权限目录表、权限表；之间采用1：0..*关系。一个权限目录，对应类，权限对应类中的方法。

注册权限的方法： 一种是，开发专门的工具（录入页面），把相关的权限（方法）输入到数据表中。另外一种是，采用java 5 annotation新特性，开发专门的工具类，在执行函数之前，预先判断是否要注册权限。

3.6    菜单

当用户使用功能或服务时，所操作链接。通常一个菜单对应着一项功能。功能通常包括：增、删、改、查等操作。

菜单的设计为：一级、两级、多级等。通常分成2级，父菜单和子菜单，父菜单对应模块的命名，子菜单对应功能。

菜单库表可以设计为子关联的，方便支持多级菜单模型扩展。也可建立菜单目录表，菜单目录和菜单建立为：1:0..*的关系，一个菜单通常只能隶属于一个菜单目录。

可以设置菜单是否显示，控制用户的功能（权限）。通常的设计方式，用户不能用的功能，把菜单设计为不可见。

3.7    角色和域的关系

对于一个软件系统，一个用户可以拥有多个角色。正如：一个人在社会上担任多个角色类似。

在设计中，角色和域是没有直接关系的，角色决定用户可以使用哪些功能，域决定用户可以操作哪些数据，也就是说角色用来区分权限，域用来区分数据。

3.8    用户、角色、权限和域的关系

系统中角色包含权限，用户对应多个角色，用户只属于一个域。如果一个权限要在某个域上可用，必须指定权限和域的关系。

关于角色和域的关系可以采用下面两种实现方式：

Ø        给角色指定域，这样在不同的域上配置不同的角色。实际上也相当于配置多个角色。

Ø        角色和权限的对应关系加上域属性，即一个角色在某个域上有哪些权限。验证权限时需要加上域属性，现在验证权限时只需要用户和权限标识，加上域属性后验证权限时需要用户＋权限标识＋域。

3.8.1            两种方式对比

对于第一种方式：         

Ø        优点：域、角色、权限三者关系比较清晰，方便数据配置，权限校验时不需要域，实现相对简单

Ø        缺点：按域定义角色会产生很多的角色定义，并且很有可能存在很多的冗余角色。如，A域下的管理员权限和B域下的管理员权限相同，但却需要定义两个管理员角色，多个域的话就会有多个相同的角色。

对于第一种方式：

Ø        好处：避免了产生冗余的角色数据，角色数据管理相对简单；

Ø        缺点：权限数据配置工作变的复杂；相对于第一点实现，权限数据可能会有级数的增加，权限验证性能上可能会受影响；权限验证逻辑也相对复杂了。

3.9    实现方式举例

    角色和域关联，但是这个关联，并不是每个域都要定义相同的角色，而是在给角色分配权限的时候，把角色和权限的对应关系加上域的属性，即，角色-权限-域；同时，在角色表中也增加域，即，角色表结构修改为 角色-域。

     举例来说，全国01，四川省0101，成都市010101，（汉字后面的数字是每个域的编码）。每个地方都有一个称之为system专员，负责分配权限的；全国的system定义了一个角色： “业务人员”，那么在角色表中就产生一条数据： 业务人员-01；然后四川省和成都市的人，都可以看到父级别的角色，即，都可以看到“业务人员”这个角色。

    四川省的system，可以为“业务人员”这个角色分配权限，然后产生的关联数据是 ：业务人员-权限-0101 ，只对四川省辖的用户起作用，对别的省不起作用；向下惯行，成都市的业务人员默认的权限也就是他的上级四川省刚刚配置的那个权限。同样，成都市的那个system也可以修改自己管辖的“业务人员”角色的权限，产生的数据是：业务人员-权限-010101。这样成都市的角色就覆盖了上级的角色权限。

如果四川省建立了自己的角色，那么别的省份是看不到的；成都市建立了新的角色，别的地市同样是看不到的。

角色只有只有被分配了权限和管理域后，才具有了行为模式。

    角色不是完全共享的，是可以分域的，而这里并不需要每个域都建立相同的冗余角色，根据管理域的分级概念，角色是可以继承的。

    对角色的分配权限，也是分域的，可以继承上级的，也可以覆盖上级。

3.10       生活中的实例

1． 政府的区域管理。中央、省、地市、县、镇、村等。

每一个省、地市等，都是区域的划分。与系统中的管理域相对应。

2． 政府的权力管理。总书记、部长、省长、市长、县长、镇长、普通民众等不同的角色。每一个人都需要和一个具体区域相关联，一个区域省长不能管理同级别的其他省或上级区域，仅能管理本省内的事务。

总书记不能对省区域内的事务直接进行管理，他只能命令省长去管理。也就是说，采用系统分层模型。每一层，都有自己的职责。各层完成本层的职责。

4       参考设计模型

4.1    菜单级别权限模型

1． 每一个菜单代表不同功能。

2． 不同的角色进行分配不同的菜单。

3． 存放菜单的表，可以设计为子关联的。

4． 可以对菜单归类，引入菜单目录的概念。一个菜单目录和菜单之间是：1：0..*的关系。

一个中小软件系统的用户权限模型参考实例：

4.2    数据操作级别权限模型

1． 数据权限可以精确到一个功能的增、删、改、查、批量增加、批量删除等操作。

2． 把细粒度的操作，专门的注册到对应的数据库表中。

3． 可以把这些操作级别的权限数据分配给角色。这也是和菜单级别权限模型，最大的区别。该模型控制的粒度更细。

4． 验证用户权限，可以通过专门的过滤器来实现。

一个中小软件系统的用户权限模型参考实例：

4.3    设计技巧

1． 在系统配置文件中，增加是否注册的标识，可以增加灵活性。

2． 在相关表中增加一个version字段（Number），通过它的数字大小来决定程序是否去注册新的权限数据。例如：初时版本是0，随后根据需要依次增加。这样的好处：

a)      当类中（权限组件）增加或修改新的方法（权限），这时需要注册，设置注册权限标识为打开，同时，把这个权限组件的版本进行调整为高数值。就可以方便的更新已有的权限。

b)      不需要删除数据库中已有的权限数据。不需要专门的sql去处理权限数据，降低了工作量。

c)      由于版本的变化，可以方便的跟踪某些权限组件的变化情况。

 

5     安全框架的选择

通常不建议自己开发安全逻辑，因为开发防攻击的安全逻辑本身就不是一个简单的任务。此外，自定义的安全逻辑可能会导致较低的可重用性。通常系统设计都是采用一些成熟的安全框架。下面是几个例子:

l         Java验证与授权服务（Java Authentication and Authorization Service, JAAS）

n         标准的认证和授权服务，他可以在可插入的身份验证模块的基础上，通过定义插入验证模块的标准，系统管理员就能够插入和配置适当的身份验证服务，以满足安全需求却无需修改组件。不过，JAAS使用的是现有的Java 2安全模型，他根据认证和授权来限制资源和代码的访问，不过，这些限制仍然局限在较低层次的系统资源，例如,读取文件或使用网络接口等。通常情况下，服务器环境下运行的代码都是可靠的且受信任的，因此，不太适合在服务器端应用JAAS授权机制。

l         Acegi安全框架

n         是一个基于Spring开发的安全框架，为应用程序提供认证和授权功能。该框架采用“Spring方式”开发，包括依赖注入、AOP拦截、针对接口编程等最佳实践。对于基于Spring的应用程序而言，Acegi提供了一个非常有用的外置式的安全架构，能够非常容易的集成到实际的应用程序中。

n         基于角色的权限管理权限控制系统，它通过一系列可配置的组件构建了一个基于Spring IoC组件装配模式的安全框架。

6       总结和展望

a)      简单的总结前面知识

b)      今后的提高部分