浅谈权限管理的对象模型和实现
2024-07-21 02:35:31
供稿：网友
1．权限治理问题的分析
1.1权限治理简要分析
任何多用户的系统不可避免的涉及到权限问题，系统的使用者越多、使用者本身的社会属性或分工越复杂，权限问题也就越复杂。无疑，无论是背负复杂办公室政治关系的办工系统、包含纵向行政关系的电子政务业务系统还是用于数据业务集成的应用集成系统，都不可避免的要解决这一问题。
我们的团队正在推动的项目是一个典型的多业务集成系统。简单的说，在这个系统中，有一个数据中心和若干具体的业务系统，各具体的业务系统在一定逻辑规则的指导下共享数据中心的数据；并且，各具体的业务系统之间也存在相互的数据和业务调用。在我们的系统构架设计中，数据中心和这些业务系统之间是一个中间层，该层容纳对数据中心数据操作的功能接口和各业务相互调用的功能接口。
权限治理即要求实现对不同用户对上述接口不同权限的访问。
1.2电子政务系统的权限治理
在与公司相关技术人员的讨论中，了解到公司已有的办公自动化或电子政务产品中的权限治理完全能够满足客户的要求。而且，在这些系统中，设计者将权限分为功能权限和资源权限。分管用户对系统功能项的访问和用户对系统所治理资源（如：公文、通知）的访问。
在这些系统中的权限设计一般是在了解客户需求、和分析服务对象的内部行政关系的基础上，将系统的用户分为若干等级，每个等级赋予对系统某些功能和资源的不同访问权限。这种用户级别往往是对服务对象行政关系的直接映射（如：科长、处长）。
1.3商业化应用系统的权限治理
在IT世界里，从来都不缺少蕴涵完善权限治理的应用系统，甚至是操作系统。得益于来自Internet的资料，我们了解到这些较成熟的系统中的权限治理是通过ACL这一中间对象来实现的。
ACL，即access Control List。中文译名：访问控制列。ACL发挥作用的原理如下：用户、或用户组通过数据库中的访问控制表得到其ACL（可以不止一个），该ACL具有一个权限――PRivilege（如：只读、读写等），同时该ACL指向某个访问项，这个访问项因所处的系统不同而不同。如：在操作系统中可能是某个文件夹，在关系数据库治理系统中可能是一个数据库，等等。实现中，用户通过ACL访问到某一具体访问项，并受该ACL所附带的权限――Privilege的限制。从而可以实现多用户对多访问项的多权限访问。
1.4他山之石
任何设计均服务于需求，由于团队所推进的系统中服务于横向联系的多业务单位，1.2所述的传统的方法建立的访问级别在实现多维权限治理时显得缺乏灵活性。所有，团队决定利用成熟的商业化应用系统中的权限治理原理结合项目的需求来实现权限治理。也即，在我们的业务集成系统中，使用ACL治理和功能模块治理来实现权限治理。下面进入技术主题：
2．权限治理子系统设计
2.1权限治理子系统的总体目标
权限治理子系统实现系统的权限治理部分的功能。以用例（User Case）分析的方法，可以得出，系统的权限治理子系统满足三种主要的功能。
A．获取访问项列表
依据预先为用户配置好的权限设置，来获取某用户所能访问的访问项列表。
B．访问可访问项
用户通过访问项列表来访问某一可访问项时，权限治理子系统给予权限控制，如：许可、不许可、只读等。
C．权限治理
设置用户、用户组与访问项之间的访问关系，也即我们熟悉的权限指派、配置等。同时，在这个设计中，使用“用户组”来归属相同权限属性的“用户”。可见，用户组是一种与权限治理直接相关的对象，所有，用户、用户组关联治理也是权限治理子用例的一个重要组成部分。
2.2权限治理子系统的对象模型
参考《权限治理对象模型(简稿)》和《“XXXX（注：屏蔽商业敏感字符）”平台权限治理子系统概要设计》，已经可以看出本次权限治理设计的对象模型的产生和实现。这里为了便于交流，作简要描述。
对象模型解释：（参考附录的名词解释）
“Function”代表系统中的可访问项，在实际应用中，可能是前述中间层的功能接口，也可能是某种业务资源，如已经生成的静态报表。具体实现时可以标签加以区别。
“ACL”代表访问控制列，连接用户、用户组、Function并拥有Privilege属性。
“Privilege”代表权限，如：禁止、只读、读写、完全控制。
“User/Group”用户，和具有相同访问属性的用户容器――用户组。之间存在多对多的关系。
“UserAccess/GroupAccess”访问关联，连接ACL和User/Group，并为其绑定权限――Privilege
实际实现是，还需实现以下逻辑：即当一个User属性多个Group时，将通过编程的方法比对权限，使得该User获得最大的权限。
现在我们可以回到1.2小节，看看本设计能否适应已有的电子政务系统的权限关联需求。
1) 可以使用Function对象来作为电子政务系统的“功能项”和“资源项”的抽象，可以使用标签来区别“功能项”和“资源项”；
2) 使用Group来模拟原有系统中的角色，使得原先用户与系统内角色之间的直接映射变为了通过Group的所属关系，并且可以为每个Group指定具体访问项的不同权限――Privilege的访问属性，便于灵活处置。
也可以为简化系统，将每个Group的对应具体Function的访问权限固定，以“角色”发布。
由此，团队认定，现在的设计可以满足普通电子政务系统的权限关联要求。
2.3注重与不足
该设计可以满足权限治理较复杂时的功能需求，但面对简单的业务系统显得很多余。并且，实现时需多表组合，并伴随大量治理模块的编写工作。并且，在系统实施阶段，还需要对系统进行软件配置操作。
3.权限治理子系统的实现
3.1面向对象的实现
在团队推进的多业务集成项目中，我们尝试使用以上的对象模型，但处于成本的考虑，我们将以上对象模型作了适当简化，取消了User对ACL的直接关联，统一使用Group归组User。
在此基础上，我们进行了数据建模，用以实现权限治理的具体功能。在完成建模后，团队还利用面向对象的方法，对该子系统进行概要设计和代码设计。（请参考《“XXXX（注：屏蔽商业敏感字符）”平台权限治理子系统概要设计》），实现是，我们引入了ACLManager和GroupManager治理类，将该子系统所有的数据库操作封装在这两个类中，并将权限治理子系统所有功能以这两个类的方法的形式发布。
该部分具体是实现，如建模细节、代码设计，可以《“XXXX（注：屏蔽商业敏感字符）”平台权限治理子系统概要设计》和测试工程DataCS中查阅。
3.2组件层与功能层对对象的包装
团队认定权限治理子系统的探索性设计应该到此为止。这样的权限治理子系统在物质上只是若干文档和几个可以相互配合工作C#类和一个测试演示工程。我们的理由是，我们已经完成对象框架的建设，在未来的具体功能实现时（假设我们的类很完美）将根据具体项目系统的要求或条件，将这些类的方法实现以不同的方式发布。如：可以将ACLManager和GroupManager包装为传统程序可用的COM，或是更时髦的.NET程序集，甚至是Web Service。对于使用java的团队，我们会乐意他们在我们的文档的帮助下用Java重新实现我们的类设计，并包装为EJB，或Web Service。
3.3整合到具体业务系统
可以看出，团队在实现系统的权限治理子系统的路上，其实并未走完。本文作者是XP软件方法（极限编程）的拥趸，相信“计划不如变化”。故在具体到某个业务系统的权限治理实现时，还需要针对具体的需求、条件对该模型进行优化、改进甚至全部推倒！
