细粒度应用授权策略研究[1]-细粒度_模块分裂_角色树_角色森林_权限管理

　　摘要：本文详细讲叙了应用中如何精确控制访问的应用授权过程，通过三个权限相关表完成对应用授权的精确细化，可以达到任意细粒度的权限访问控制要求。目前本文描述的应用授权体制已经在应用中得到实现，和原应用授权控制相比较，授权管理简单，具备更实际的操作性。

　　引言

　　计算机应用系统对安全越来越重视，传统的授权模式受到了严峻的挑战。以前，很多应用只要操作员有权登陆，就可以操作该系统下的任何模块;严格点的控制也只体现在菜单颜色变灰，阻止操作员登陆该模块(或者根据不同登陆人员挂不同的菜单)。要实现某部分模块即要让操作员能够浏览，又不能修改，传统模式是开发两套程序模块：一个用于查询浏览，另外一个用于修改维护。这种设计方式在代码维护上非常困难：程序员常常修改了用于“修改维护”的模块而忘记了“查询浏览”的模块，导致查询浏览看到的数据和修改维护界面看到的数据不一致。有些应用系统如办公自动化，用户群庞大，授权操作通常由专门的人历时数月进行维护，而且难以做到在同一模块下，不同用户在浏览和修改权限上的细粒度控制。

　　笔者曾经参与的一个人事管理系统项目，对权限管理要求非常细，例如：同样是可以登陆系统的用户，对于同一个程序模块，根据自身级别的不同，可以对部分数据进行修改，对部分数据进行浏览，而对部分数据连浏览的权限都没有，传统的基于模块级的授权模式无法解决这个问题;而且，这种细粒度访问授权还要对新增用户有效，并且授权方式不能太复杂，否则授权模式的培训就成为项目试点的难点。经多次讨论，终于找到了一种授权配置简单，授权粒度控制精确的方法，比较高效的解决了这个问题。

　　1应用权限分配策略

　　授权问题的关键是用户可维护，用户允许登陆模块可维护和用户登陆模块后，访问数据权限可维护[1]。

　　对于登陆用户，控制其能够操作的数据可以通过数据库的字段标记或者以视图的形式加以限制。通过视图等手段我们可以实现将登陆用户无权访问的数据隐藏。由于数据库在这方面已经非常完善，所以我们不赘述。

　　本文着重表述的是对用户能够访问的数据，登陆用户是否有权访问该模块，是只有读权限还是有读写权限。

　　我们设计了程序模块表(programe_module)，用户角色表(user_role)，角色模块表(role_module)组成共同的授权体系，等登陆人员进行权限审核。

　　1.1程序模块粒度细化

　　应用授权管理的关键是程序模块细化粒度。程序模块表中的模块概念是对传统模块概念的扩充。传统意义的程序模块划分是以完成某一特定功能为标准，将相关功能组合在一起，形成一个功能模块[3]。而细粒度应用授权中的模块概念，是在功能模块划分的基础上，对于任何登陆用户，同一模块中的所有对象，要么具备整体访问权限，要不不具备该模块中任何对象的访问权限;对于模块中的对象，如果只对部分对象具备某权限，该模块就必须分裂，哪怕这些功能域分布在同一个程序界面。通常，分裂最终形成一个没有交集，且并集是全集的模块的模块集合。这个模块集合为一个树型结构[2]，节点上的授权既可以保证对子节点的访问，又可以避免权限分配的交叉。这个树型程序访问权限模型保证最底层的权限是最具体的和最小的。

　　例如：程序界面有三个数据域A，B，C，假定有两种类型的用户，甲类用户能够读A，B，C三个域，但是只能修改A，B。乙类用户只能浏览到A，B。我们将该部分程序做如下模块划分，第一，将A和B作为一个大模块，模块名称private_ab_readandwrite，C作为一个小模块private_c_readandwrite;第二，将A和B的读作为大模块的子模块private_ab_read，将A和B的写作为大模块的子模块private_ab_write。当然我们完全有理由将A、B和C的权限分别分解成private_a_read，private_a_write，private_b_read……private_c_write。但是，这样我们形成的模块数将会太多，不方便以后的对模块的授权操作。总之，原则一条，同一最低层模块中的权限应该是一样的，但是尽量生成最少的模块。

　　1.2角色的创建

　　创建角色极大的方便了权限管理。当用户量、程序模块数都很多的时候，通过为每个用户赋予几个角色就可以完成授权，而不用为每个用户分别赋予每个模块的读写权限，可以极大的减少授权的工作量，同时，授权过程相对简单，也减少了试点的压力。笔者曾看到过一个办公自动化系统，就有专门的人成年累月的维护一个没有角色层的授权体制。由于缺少了角色层，大用户群造成了巨大的工作量，而且经常出错。