浅谈权限管理的对象模型和完成
日期：2013-10-30 浏览次数：20728 次
浅谈权限管理的对象模型和实现 beegee（原作） 关键字 权限管理 对象模型 ACL 电子政务
浅谈权限管理的对象模型和实现
beegee （2003-7-16）
目录：
1．权限管理问题的分析
1.1权限管理简要分析
1.2电子政务系统的权限管理
1.3商业化使用系统的权限管理
1.4他山之石
2．权限管理子系统设计
2.1权限管理子系统的总体目标
2.2权限管理子系统的对象模型
2.3留意与不足
3．权限管理子系统的实现
3.1面向对象的实现
3.2组件层与功用层对对象的包装
3.3整合到具体业务系统
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．权限管理
设置用户、用户组与访问项之间的访问关系，也即我们熟悉的权限指派、配置等。同时，在这个设计中，使用“用户组”来归属相反权限属性的“用户”。可见，用户组是一种与权限管理直接相关的对象，所有，用户、用户组关联管理也是权限管理子用例的一个重要组成部分。
图1：权限管理子系统用例
2.2权限管理子系统的对象模型
参考《权限管理对象模型(简稿)》和《“XXXX（注：屏蔽商业敏感字符）”平台权限管理子系统概要设计》，曾经可以看出本次权限管理设计的对象模型的产生和实现。这里为了便于交流，作简要描述。
图2：权限管理子系统对象模型
对象模型解释：（参考附录的名词解释）
“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管理类，将该子系统所有的数据库操作封装在这两个类中，并将权限管理子系统所有功用以这两个类的方法的方式发布。
图3:
该部分具体是实现，如建模细节、代码设计，可以《“XXXX（注：屏蔽商业敏感字符）”平台权限管理子系统概要设计》和测试工程DataCS中查阅。
3.2组件层与功用层对对象的包装
团队认定权限管理子系统的探索性设计应该到此为止。这样的权限管理子系统在物质上只是若干文档和几个可以互相配合任务C#类和一个测试演示工程。我们的理由是，我们曾经完成对象框架的建设，在未来的具体功用实现时（假设我们的类很完满）将依据具体项目系统的要求或条件，将这些类的方法实现以不同的方式发布。如：可以将ACLManager和GroupManager包装为传统程序可用的COM，或是更时髦的.NET程序集，甚至是Web Service。对于使用Java的团队，
浅谈权限管理的对象模型和实现
beegee （2003-7-16）
目录：
1．权限管理问题的分析
1.1权限管理简要分析
1.2电子政务系统的权限管理
1.3商业化使用系统的权限管理
1.4他山之石
2．权限管理子系统设计
2.1权限管理子系统的总体目标
2.2权限管理子系统的对象模型
2.3留意与不足
3．权限管理子系统的实现
3.1面向对象的实现
3.2组件层与功用层对对象的包装
3.3整合到具体业务系统
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．权限管理
设置用户、用户组与访问项之间的访问关系，也即我们熟悉的权限指派、配置等。同时，在这个设计中，使用“用户组”来归属相反权限属性的“用户”。可见，用户组是一种与权限管理直接相关的对象，所有，用户、用户组关联管理也是权限管理子用例的一个重要组成部分。
图1：权限管理子系统用例
2.2权限管理子系统的对象模型
参考《权限管理对象模型(简稿)》和《“XXXX（注：屏蔽商业敏感字符）”平台权限管理子系统概要设计》，曾经可以看出本次权限管理设计的对象模型的产生和实现。这里为了便于交流，作简要描述。
图2：权限管理子系统对象模型
对象模型解释：（参考附录的名词解释）
“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管理类，将该子系统所有的数据库操作封装在这两个类中，并将权限管理子系统所有功用以这两个类的方法的方式发布。
图3:
该部分具体是实现，如建模细节、代码设计，可以《“XXXX（注：屏蔽商业敏感字符）”平台权限管理子系统概要设计》和测试工程DataCS中查阅。
3.2组件层与功用层对对象的包装
团队认定权限管理子系统的探索性设计应该到此为止。这样的权限管理子系统在物质上只是若干文档和几个可以互相配合任务C#类和一个测试演示工程。我们的理由是，我们曾经完成对象框架的建设，在未来的具体功用实现时（假设我们的类很完满）将依据具体项目系统的要求或条件，将这些类的方法实现以不同的方式发布。如：可以将ACLManager和GroupManager包装为传统程序可用的COM，或是更时髦的.NET程序集，甚至是Web Service。对于使用Java的团队，
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
