建筑规划管理软件

 　　建筑行业企业规划管理系统规模的不断扩大，通常会加大系统权限管理的难度。权限管理方案和实现方法的不合理，往往会导致权限泛滥，或失去足够的灵活性。本文介绍了泛普基于项目与角色的访问控制(P-RBAC)策略，并结合城市规划项目，与实际业务相结合，提出了一套权限管理高效的解决方案和具体实现方法。通过实际生产应用，证明了此方案不仅可以满足企业信息系统权限管理的要求，而且使权限管理具有很高的灵活性和可操作性。

　　一、 背景及访问控制模型分析

　　随着城市规划业务的发展，以前基于某个功能的应用程序已不能满足需要，全面化、系统化已成为为业务系统的必然趋势。项目管理系统的不断扩大，系统的权限管理成为一个日益突出的问题。城市规划项目管理系统具有严格的流程控制管理，对应的流程又具有丰富的功能。系统中存储大量的规划数据资源。合理控制众多用户对数据资源的访问权限，对于保证系统数据的安全，明确用户的责任，都有着重要的意义。

　　近20年来，人们在访问控制的研究方面取得了很大成果，有许多访问控制模型被提出来。20世纪70年代，Harrison， Ruzzo和Ullman提出了HRU模型。接着，Jones等人在1976年提出了Take-Grant模型。后来，又有著名的自主访问控制模型(DAC)和强制访问控制模型(MAC)提出来了。

　　随着应用复杂度的不断提高，传统的访问控制(比如基于Subject-Object 的MAC 和DAC 方式)越来越显现出其局限性，其几乎静态化的个体——资源控制已经无法适应复杂多变的应用系统——资源的变动、人员的变动，以及系统/任务之间相互协调和关联关系。在这种情况下， Ferraiolo和Kuhn在1992年提出了基于角色的访问控制模型(role-based access control)

　　目前基于角色和基于任务访问控制方式，被广泛的采纳。基于角色的访问控制(RBAC)是在自主访问控制(Discretionary Access Control)和强制访问控制(Mandatory Access Control)的基础之上发展起来的，RBAC与访问者的身份认证密切相关，通过确定合法访问者的身份来确定访问者在系统中对哪类资源有什么样的访问权限。一个访问者可以充当多个角色，一个角色也可以由多个访问者担任。每个角色与一组用户及相关的动作相互关联，承担某一角色的用户有权执行赋予该角色的操作，对相关资源进行访问。

　　下面我们看看常用的几种访问控制(Access Control)特点：

　　1、自主访问控制(DAC)

　　优点：所有的主体和客体都在系统中列举出来，并且给予每个主客体以明确的授权。基于所有权的、客体的拥有者可以任意将该客体的访问权限授予其他主体。

　　缺点：一个客体被授权给另一个用户后，对该客体的复制权限就无法控制。

　　2、强制访问控制(MAC)

　　优点：基于管理的、所有的主体和客体都会根据实现定义的敏感级别进行分类。

　　MAC的一个重要目的就是保证信息的机密性和完整性。通过级别控制信息流的方向，no read-up and no write-down或Chinese Wall policy。所谓no read-up就是说：低级别的主体不能从高级别的客体中读取信息。所谓no write-down就是说：高级别的主体不能向低级别的客体中写入信息。以上两点约束都是方式信息流从高级别流向低级别。从而保证信息的安全。

　　缺点：缺乏灵活性，完整的实施也比较繁琐。

　　3、基于任务的访问控制

　　优点：倾向基于应用层的控制，是一种主动式安全模型。主动式安全模型：这种安全模型，更多的从活动或任务的角度看待安全和实施的控制问题，它抽象出了一种控制机制，用于任务运行期间的管理。其同时也抽象出任务之间的一些访问/授权关联关系，比如只有当任务A 被授权访问后，任务B 才能被授权访问。所以，在主动式的安全模型中，许可就不是一个固定的状态，授权和许可等行为都在被不断的监控，许可状态也随着不断的变化。在基于任务的访问控制中，更多体现出授权许可状态，以及任务与任务之间的关联关系。其中，许可状态则是授权许可的结果反映。

　　4、基于角色的访问控制

　　优点：最小授权原则;

　　策略独立

　　基于角色的接入控制(RBAC)是超级用户模型的替代型方案，它将超级用户的权限分离，打包进特殊的用户帐户或者角色，最后按照专门个人的工作需要而分配给他们。遵守最小特权的安全原理，规定任何用户除了为执行他个人的工作外，不会给予他更多的特权。这样在一定程度上可简化授权操作。使访问控制适应性更强，管理者可以通过调整用户所属角色及角色之间的层次，灵活地控制用户访问资源;不仅这样，还可以很容易地将角色与内部人事结构结合起来，达到简化管理、明确责任目的。

　　二、 泛普建筑规划管理软件的方案设计

　　权限管理的核心，就是对不同权限的用户，在适当的时候分配对应权限的资源。

　　一般来说，现在的行政管理方式都或多或少实现了矩阵式管理，系统的权限与之对应。通常，一个项目负责人员属于某个项目小组(部门)，这是行政范围，但在参与项目时，又在某段时间内属于项目，同时拥有了项目中的权限。 项目小组(部门)中的这类对象之间一般有所属关系，如中心、部门、小组等。对于人员参与项目来说，在项目周期中，增加了项目权限，如看项目中的文档、建立和修改文档等。 那么，根据以上两种类型的分类，权限和角色也同样分为两类，行政上的角色是相对稳定的，在员工入职时就可以授予，在行政调动时再修改，离职时收回。而对于项目来说，角色相对不稳定，只是在项目的生命周期中才有该角色和权限。

　　基于角色的访问控制(RBAC)机制由于具有较高的可扩展型和灵活性，我们结合城市规划项目管理实际，采用RBAC机制，提出基于项目与角色的访问控制(P-RBAC)策略。现将逻辑判断、资源和角色进行如下设计：

　　1、逻辑判断

　　权限逻辑判断使用五元组实现(角色，项目，模板，流程，条件控制[是否部门相关，通知付款相关])进行控制，其中条件控制可以根据实际的情况给出控制条件

　　2、资源分类

　　系统操作功能：使用菜单形式进行表现，在系统登录的同时检测那些菜单可以显示来控制权限。

　　项目操作功能：在项目的操作功能区进行显示，在用户访问的同时采用自主访问方式实现权限的判断。

　　3、角色类型

　　在用户组织模型中，采用了“项目流程内”项目角色与“跨流程全局”的系统角色相结合。为了便于管理和应用，把角色按照实际情况进行分类。

　　从形式上分普通角色，实际上就是一般意义上角色。只是为了与下面的几个角色类型区分，特意加上“普通”一词;动态角色，项目运转中，会依据其所属的状态，而分配获取相应的权限。

　　从应用范围上分项目角色，在项目流程定义的时候，才会根据项目流程的中会存在有哪些执行人(执行角色)来的来定义。这些角色仅仅只能在当前项目当前流程内使用;系统角色，同一个系统中，可存在项目并行，对于项目流程内的角色，各个流程之间是独立的，透明的。例如文档审批人员，在任何项目中候选及本上都是相同的，只是根据实际提交情况再次确认。