基于角色的访问控制(RBAC)及应用研究

基于角色的访问控制（RBAC）及应用研究

姓名：刘萍申请学位级别：硕士专业：计算机技术指导教师：傅彦20041209

摘要近年来，随着全球网络化的热潮，网络技术正在日益广泛而深入地被应用到社会的各个领域中，并深刻地改变着社会的行为和面貌。然而，与此同时，网络安全却成为日益严重的问题。为此，国际标准化组织ＴｓＯ在网络安全体系的设计标准（ＩＳ０７４９８—２），提出了层次型的安全体系结构，并定义了五大安全服务功能：身份认证服务，访问控制服务，数据保密服务，数据完整性服务，不可否认服务。访问控制服务是网络安全的一项重要内容，访问控制（ＡｃｃｅｓｓＣｏｎｔｒ０１）就是通过某种途径显式地准许或限制访问能力及范围的一种方法。传统的访问控制技术丰要分为两大类，即自主型的访问控制ＤＡＣ（ＤｉＳｃｒｅｔｉｏｎａｒＹ强制型的访问控制ＭＡＣ（ＭａｎｄａｔａｒｙＡｃｃｅｓｓＡｃｃｅｓＳＣｏｎｔｒ０１）和Ｃｏｎｔｒ０１）。这两种访问控制方式有其明显的不足，ＤＡＣ将赋予或取消访问权限的一部分权力留给用户个人，不利于实现统一的全局访问控制。而ＭＡＣ在系统连续工作能力、授权的可管理性等考虑不足。９０年代以来出现的一种基于角色的访问控制ＲＢＡＣ（Ｒｏｌｅ—ＢａｓｅｄＡｃｃｅｓＳＣｏｎｔｒ０１）技术有效地克服了传统访问控制技术中存在的不足之处，借助于角色这个主体，用户通过角色访问资源，大大提高了管理的效率，减少授权管理的复杂性，降低管理开销，而且还能为管理员提供一个比较好的管理环境。因此ＲＢＡＣ这种新型的访问控制技术，为网络安全中的访问控制提供了一个高效、方便、易用的模型，具有很广阔的应用发展前景。在这个项目中，我参与了项目的总体及方案设计，了解用户需求，参与设计应用方案，负责将学校的科研成果转化成公司的应用成果，并负责整个项目的项目管理。本文包括以下内容：１．首先介绍了ＲＢＡＣ的来源和背景，并讨论了访问控制的一些技术。２．针对ＲＢＡＣ的理论研究，包括ＲＢＡＣ的核心和模型。３．ＲＢＡＣ的具体的设计和实现，包括总体结构、功能模块、关键技术的设计和实现。４．ＲＢＡＣ的典型应用。关键词：角色、访问控制、ＲＢＡＣＡｂｓｔｒａｃｔＩｎｒｅｃｅｎｔｙｅａｒｓ，ａｌｏｎｇｗｉｔｈｔｈｅｔｉｄｅｏｆｇｌｏｂａｌｉｎｔｅｒｎｅｔ，ｎｅｔｗｏｒｋｔｅｃｈｎｏｌｏｇｙｈａｓａｌｒｅａｄｙｂｅｅｎｕｓｅｄｉｎｍａｎｙｆｉｅｌｄｓｅｘｔｅｎｓｉｖｅｌｙ，ａｎｄｉｔｗｉｌｌｃｈａｎｇｅｔｈｅｆｅａｔｕｒｅｏｆｔｈｅｓｏｃｉｅｔｙ．Ａｔｔｈｅｓａｍｅｔｉｍｅ，ｔｈｅｓａｆｅｔｙｏｆｎｅｔｗｏｒｋｉｓｂｅｃｏｍｉｎｇｓａｆｅｔｙａｍｏｒｅａｎｄｍｏｒｅｓｅｒｉｏｕｓｐｒｏｂｌｅｍ．ＩＳＯｐｕｔｆｏｒｗａｒｄｓｙｓｔｅｍａｂｏｕｔｔｈｅｄｅｓｉｇｎｏｆｓｔａｎｄａｒｄｓａｆｅｔｙｏｆａｌａｙｅｒｏｆｓａｆｅｔｙｓｔｒｕｃｔｕｒｅｎｅｔｗｏｒｋｓｙｓｔｅｍ，ａｎｄｓｅｒｖｉｃｅ，ａｃｃｅｓｄｅｆｉｎｅｄｓｆｉｖｅｆｕｎｃｔｉｏｎｓｓｅｒｖｉｃｅ：ａｕｔｈｅｎｔｉｃａｔｉｏｎｃｏｎｔｒｏｌｓｅｒｖｉｃｅ，ｓｅｃｕｒｉｔｙｓｅｒｖｉｃｅ，ｉｎｔｅｇｒｉｔｙｓｅｒｖｉｃｅ，ｎｏｄｅｎｉａｌａｎｓｅｒｖｉｃｅ．Ａｃｃｅｓｓｃｏｎｔｒｏｌｓｅｒｖｉｃｅｉｓａｉｍｐｏｒｔａｎｔｉｔｅｍｏｆｎｅｔｗｏｒｋｓａｆｅｔｙ．Ｉｔｉｓｔｅｃｈｎｏｌｏｇｙｈａｓｔｗｏｓｓｗａｙｔｏｐｅｒｍｉｔｏｒｌｉｍｉｔａｃｃｅｓｓ．Ｔｒａｄｉｔｉｏｎａｌｗａｙｓ：ＤＡＣｆＤｉｓｃｒｅｔｉｏｎａｒｙＡｃｃｅｓｓＣｏｎｔｒ０１）＆ＭＡＣ（ＭａｎｄａｔｏｒｙａＡｃｃｅａｃｃｅｓｓＣｏｎｔｒ０１）．Ｂｕｔｂｏｔｈｈａｖｅｅｖｉｄｅｎｔｓｈｏｒｔａｇｅｓ，ＤＡＣｓｈａｒｅｓｔｈｅｒｉｇｈｔｏｆｔｏｐｅｒｓｏｎａｌｕｓｅｒｓ，ｔｈａｔｗｉｌｌｂｒｉｎｇｄｉｓａｄｖａｎｔａｇｅｓｔｏｔｈｅｏｖｅｒａｌｌｈａｓｍａｎｙｗｅａｋｎｅｓｓｅｓａｂｏｕｔｃｏｎｔｉｎｕｏｕｓｌｙＡｃｃｅｓｉｔｕａｔｉｏｎａｎｄｃｏｎｔｒ０１．ＭＡＣｗｏｒｋｓｓｃｏｎｔｒ０１Ｌａｂｉｌｉｔｙｏｆａｕｔｈｏｒｉｚａｔｉｏｎ．Ｉｎ９０ｓ，ＲＢＡＣ（Ｒｏｌｅ－ＢａｓｅｄＣｏｎｔｒ０１）ｃ，ｆｓａｖａｉｔａｂｌｙｏｖｅｒｃａｍｅｔｈｅｗｅａｋｎｅｓｓｏｆｔｒａｄｉｔｉｏｎａｌｒｏｌｅｓｔｅｃｈｎｏｌｏｇｙ．Ｗｉｔｈｔｈｅｈｅｌｐｔｈｒｏｕｇｈａｃｏｒｐｕｓ，ｃｕｓｔｏｍｃａｎａｃｃｅｓｓｒｅｓｏｕｒｃｅｓｒｏｌｅｓ．Ｉｔｍａｋｅｍａｎａｇｅｍｅｎｔｍｏｒｅｅｆｆｉｃｉｅｎｃｙａａｎｄｐｒｏｖｉｄｅｓｂｅｔｔｅｒｍａｎａｇｅｍｅｎｔｅｎｖｉｒｏｎｍｅｎｔ．Ｓｏ，ＲＢＡＣｈａｓｉｔｅｍ，Ｉｖｅｒｙｗｉｄｅｄｅｖｅｌｏｐｍｅｎｔｆｏｒｅｇｒｏｕｎｄ．Ｉｎｔｈｉｓｐａｒｔｉｃｉｐａｔｅｄｔｈｅｗｈｏｌｅｐｒｏｊｅｃｔｄｅｓｉｇｎ，ｇｏｔｔｈｅｍｅｓｓａｇｅｆｒｏｍｃｕｓｔｏｍｅｒｓ，ｔｏｏｋｐａｒｔｉｎｔｈｅａｐｐｌｉｃａｔｉｏｎｆｏｒｔｕｒｎｉｎｇｔｈｅｐｒｏｊｅｃｔｄｅｓｉｇｎａｎｄｗｅｒｅｒｅｓｐｏｎｓｉｂｌｅｓｃｉｅｎｃｅｒｅｓｕｌｔｉｎｔｏａｐｐｌｉｃａｔｉｏｎｒｅｓｕｌｔ．Ａｔｔｈｅｓａｍｅｔｉｍｅ，１ｗｅｒｅｒｅｓｐｏｎｓｉｂｌｅｆｏｒｔｈｅｍａｎａｇｅｍｅｎｔｏｆｔｈｅｗｈｏｌｅｉｔｅｍ．Ｔｈｉｓｐａｐｅｒｉｎｃｌｕｄｅｓ：１．ｂａｃｋｇｒｏｕｎｄｏｆＲＢＡＣａｎｄｓｏｍｅｉｎｆｏｒｍａｔｉｏｎａｂｏｕｔａＣＣｅＳＳｃｏｎｔｒ０１．２．ｔｈｅｏｒｉｅｓｒｅｓｅａｒｃｈｏｆＲＢＡＣ．ｉｎｃｌｕｄｉｎｇｔｈｅｃｏｒｅ＆ｍｏｄｅｌ．３．ｃｏｎｃｒｅｔｅｄｅｓｉｇｎａｎｄｒｅａｌｉｚａｔｉｏｎｏｆＲＢＡＣ，ｉｎｃｌｕｄｉｎｇｗｈｏｌｅｓｔｒｕｃｔｕｒｅ，ｆｕｎｃｔｉｏｎｍｏｄｕｌｅ，ｋｅｙｔｅｃｈｎｏｌｏｇｙｅｔｃ．４．ｔｙｐｉｃａｌａｐｐｌｉｃａｔｉｏｎｏｆＲＢＡＣ．Ｋｅｙｗｏｒｄｓ：Ｒｏｌｅ，ＡｃｃｅｓｓＣｏｎｔｒｏｌ，ＲＢＡＣ．独创性声明本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示谢意。签名：咩日期：歹吨ｒ年ｆ月嘭日关于论文使用授权的说明本学位论文作者完全了解电子科技大学有关保留、使用学位论文的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。（保密的学位论文在解密后应遵守此规定）虢斗ｚ熹基于角色的访问控制（ＲＢＡＣ）及应用研究第一章引言１．１访问控制技术概述近年来，随着全球网络化的热潮，网络技术正在目益广泛而深入地被应用到社会的各个领域中，并深刻地改变着社会的行为和面貌。然ｊｆＩ．『，与此同时，网络安全却成为日益严重的问题。尤其在商业、金融和国防等领域的网络应用中，能否保证网络具有足够的安全性是首先要考虑的问题。安全问题如果不能有效地得到解决，必然会影响整个网络的发展。为此，国际标准化组织ＩＳ０在网络安全体系的设计标准（ＩＳ０７４９８—２）中，提出了层次型的安全体系结构，并定义了五大安全服务功能：身份认证服务，访问控制服务，数据保密服务，数据完整性服务，不可否认服务。一个可靠的网络，它的可信任程度依赖于所提供的安全服务质量。访问控制（ＡＣｃｅｓＳＣＯｎｔｒ０１）就是通过某种途径显式地准许或限制访问能力及范围的一种方法。通过访问控制服务，可以限制对关键资源的访问，防止非法用户的侵入或者因合法用户的不慎操作所造成的破坏。传统的访问控制技术主要分为两大类，即自主型的访问控制ＤＡＣ（ＤｉＳＣｒｅｔｉｏｎａｒＹＡｃｃｅｓｓＣｏｎｔｒ０１）和强制型的访问控制ＭＡＣ（ＭａｎｄａｔａｒＹＡｃｃｅｓｓＣｏｎｔｒ０１）。这两种访问控制方式有其明显的不足，ＤＡｃ将赋予或取消访问权限的一部分权力留给用户个人，这使得管理员难以确定哪些用户对哪些资源有访问权限．不利于实现统一的全局访问控制。而ＭＡｃ由于过于偏重保密性，对其他方面如系统连续工作能力、授权的可管理性等考虑不足。对于国内的很多公司，尤其是比较大的公司和政府机构．需要管珲的信息资源数量非常多，并且职员的数量也很多，如果采用传统的访问控制策略，将会使信息共享和信息安全的管理，变成及其繁琐和困难。９０年代以来出现的一种基于角色的访问控制ＲＢＡＣ（Ｒｏｌｅ—ＢａＳｅｄＡＣＣｅｓｓＣｏｎｔｒ０１）技术有效地克服了传统访问控制技术中存在的不足之处，借助于角色这个主体，将原来成千上万的用户抽象成角色，用户通过角色访问资源，建立这样一种映射关系，大大提高了管理的效率，减少授权管理的复杂性，降低管理开销，而且还能为管理员提供一个比较好的实现安全政策的环境。基于角色的访问控制（ＲＢＡＣ）及应用研究在ＲＢＡＣ中，引入了角色这一重要概念。所谓“角色”，就是一一个或一群用户在组织内可执行的操作的集合。ＲＢＡＣ的基本思想是：授权给用户的访问权限，通常由用户在一个组织中担当的角色来确定。例如，一个银行包含的角色可以有出纳员、会计师和贷款员等。由于他们的职能不同，所拥有的访问权限显然也各不相同。ＲＢＡＣ根据用户在组织内所处的角色来进行访问授权与控制。也就是说，传统的访问控制直接将访问主体（发出访问操作、存取要求的主动方）和客体（被调用的程序或欲存取的数据）相联系，而ＲＢＡＣ在中间加入了角色，通过角色作为桥梁来沟通主体与客体；真正决定访问权限的是用户对应的角色。ＲＢＡＣ对访问权限的授权由管理员统一管理，而且授权规定是强加给用户的，用户只能被动接受，不能自主地决定；用户也不能自主地将访问权限传给他人。这是一种非自主型的访问控制。因此ＲＢＡＣ这种新型的访问控制技术，为网络安全中的访问控制提供了一个高效、方便、易用的模型，具有很广阔的应用发展前景。下面分别对这几种访问控制技术进行介绍。１．１．１自主访问控制（ＤＡＯ）技术自主访问控制是目前计算机系统中实现最多的访问控制机制，其基本思想是：允许某个主体显式地指定其他主体对该主体所拥有的信息资源是否可以访问以及可执行的访问类型。如Ｗｉｎｄｏｗｓ和ｕｎｉｘ就是这种类型。它的特点是根据主体的身份和授权规则来决定访问模式。授权规则描述了系统中每个主体允许对客体进行的操作方法或者访问方式（如读、写或执行）。每个用户对客体进行访问的要求都要经过规定的检验。如果授权中允许用户以这种方式访问客体，则访问就可以得到许可；否则就拒绝访问请求。自主访问控制机制允许对象的属主来制定针对该对象的保护策略。自主访问控制ＤＡｃ由于其易用性与可扩展性，使自主访问控制技术能够适用于多种系统及应用，尤其在商业和工业环境中被广泛应用。１．１．２强制访问控制（ＭＡＯ）技术强制访问控制是“强加”给访问主体的，即系统强制主体服从访问控制政策。它预先定义主体的可信任级别和客体（信息）的敏感程度（安全级别），根据主体和客体的级别标记来决定访问模式，如绝密级、机密级、秘密级和无密级。它的访问控制关系分为上读／下写（保证数据基于角色的访问控制（ＲＢＡＣ）及应用研究的完整性）和下读／上写（保证数据的机密性），并通过安全标签实现单向信息流通模式。这种访问控制方式主要适合于多层次安全级别的军事应用。ＭＡＣ技术用来保护系统确定的对象，对此对象用户不能进行更改。也就是说，系统独立于用户行为之外强制执行访问控制，用户不能改变它们的安全级别和对象的安全属性。这样的访问控制规则通常对数据和用户按照安全等级划分标签，访问控制机制通过比较安全标签来确定的授予还是拒绝用户对资源的访问。强制访问控制进行了很强的等级划分，所以经常用于军事用途。在强制访问控制系统中，所有主体（用户，进程）和客体（文件，数据）都被分配了安全标签，安全标签标识一个安全等级。主体（用广，进程）被分配一个安全等级，客体（文件，数据）也被分配～个安全等级，访问控制执行时对主体和客体的安全级别进行比较。１．２国内外研究动态国外的许多机构，包括ＮＩＳＴ（ＮａｔｉｏｎａｌＩｎｓｔｉｔｕｔｅｏｆＳｔａｎｄａｒｄｓａｎｄＴｅｃｈｎｏｌｏｇｙ）从１９９０年开始就在为定义ＲＢＡＣ标准而工作，并且推动这项技术的研究和开发。ＲＢＡＣ的发展经历了由简单到复杂的过程，通过对ＲＢＡＣ定义的分析，Ｓａｎｄｈｕ将ＲＢＡＣ的模型分成卜４级，ＲＢＡＣＯ是ＲＢＡＣ的基本模型，它包含最小权限原则和职责分离原则，ＲＢＡＣ卜３都是在ＲＢＡＣＯ的基础上，增加了继承和约束的新概念加强安全和管理（如表１～１）。ＮＩＳＴ的这种模型最为业界认可。衰Ｉ—ＩＲＢＡＣ模型级别下表ｉ一２是一个ＲＢＡＣ产品功能对比表，可以看出，大部分产品没有达到ＲＢＡＣ３级的水平。基于角色的访问控制（ＲＢＡＣ）及应用研究性能支持角色拥用户可支持缺支持静支持动支持角支持目支持可支持有者将自身以同时省的活态职责态职责色继承标访问视化角角色授与其使用多动角色分离它用户个角色√××支持角色ＲＦ｛ＡＣ分离对象授色编辑＿＿：次开容量权管理厘√√×ＲＢＡＣＶｌ－ＯＩｎｆｏｒｍｉＸ×√××√√√√√×Ｘ√××ＸＳｙｂａｓｅＯｒａｃｌｅ√√√×√×√×√√√√×××√×√√√××××ＷｉｎｄｏｗｓＮＴ／２．ＯＯＯ×××××Ｉ蹦ＴｉＶＯＩｉＮＩＳＴ√√√√√√√√√√√√×√√√Ｒ卧Ｃ√√√、ｉ同时，国外许多软件开发商现在提供ＲＢＡＣ以及与ＲＢＡＣ相关的产品下表１—３是提供包解决方案（ＰａｃｋａｇｅＳ０１Ｕｔｉｏｎｓ）厂家名单。表１—３Ａ“Ｐ蛘ｍｎｌｎ（ＲＢＡＣ包解决方案提供厂商ＲＳＡＳＰｃｕｒｌ时，Ｉｎ‘＾ｄｒ、×．１‰Ｉ甜Ａ、～ｑ｜－ｍ、…ＩｓｅｃＬＩｌｅ（ｏｍｐｕｔｉｎＲ（ｊ｛，ｍ‘附ｎ１Ｐｎ、Ａ．ＧＣｉ’ｃｏＩｖ¨ｅｌＴＩＳＩｎｃＩＩｎｌｌｌｙ，Ｉ轧ＩＡＣＯｌｐ、ｕ１１ＩｍＭｉＬｌｆｌ椎‘Ｉｔ・ｆｌＩＦ．ＩｖＩｌｌｆＴＩＳＬＩｎｋＰＩＩＩｌａＬｌ（｝１１‰１ｕｒｉｔｙＣｆ）ｒｐ、ｖ【ｘｌ”，ｈｌｆ％ｙｌｌｌａｌｌｉ州ｉ¨｜ｐ、、。、１１１１Ｉｍｆ、ｍ．…（Ｉｎｄ｜｜㈨ｑｎ惜§Ｍａｃｈｉｍ’（ｏｒｐＩｎｔｅｒｌｌｉ—ｆ‰１－ｕｒｉｔ７％ｖｓｔＰｒｌｈｈｌ（ＡＧｆｆ’Ｊ．Ｊｆ＂ＩＦ－（ｒ，盯ｍ’升１ｐＲ１Ｊｕ…）ｎ‘Ｔｉｖｌ）ＩＪ∞Ⅲ，ｍ‘，ＩｍＭｉｃｒＩ）ｓｏｌ［（ｏｒｐＮｅｔ、，；ｏｒｋＡｓｓｏｃｉａｔｅｓ，ＩｎｃＶｉ；：ｎｌｅｔｔｅ（ｉｌｒｐ［］ａｌｔｉｍｏｒｅＴｅｃｈｎｏｌｏｇｉｅｓ，ＩｎｃＩ）ｊｕ！ｎＮＰＩ’ＡＩ从Ｍ’ｈｎｍⅫｎ，Ｉｎ（ｃｍ州ｐｆｏ“Ｍ（ｋ¨Ｍａ№Ｉｎ（ＮＩ）ｖｅｌｌＣｎｒｐｒｐ而国内与国外比较，在ＲＢＡＣ的研究和产品化方面显得落后，目前只有学术机构如中科院研究所等对ＲＢＡＣ规则进行研究，尚无比较成熟基于角色的访问控制（ＲＢＡＣ）及应用研究的ＲＢＡＣ安全访问控制产品。１．３ＲＢＡＯ在实际应用方面的意义和价值ＲＢＡＣ对访问权限的授权由管理员统一管理，而且授权规定是强加给用户的，用户只能被动接受，不能自主地决定。用户也不能自主地将访问权限传给他人。这是一种非自主型访问控制。用户以什么样的角色对资源进行访问，决定了用户拥有的权限以及可执行何种操作。所以在ＲＢＡＣ中，访问的主体变成了角色。为了提高效率，避免相同权限的重复设置，ＲＢＡＣ采用了“角色继承”的概念，定义了这样的一些角色，它们有自己的属性。但可能还继承其他角色的属性和权限。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。ＲＢＡＣ的最大优势在于它对授权管理的支持。通常的访问控制实现方法，将用户与访问权限直接相联系，当组织内人员新增或有人离开时，或者某个用户的职能发生变化时，需要进行大量授权更改工作。而在ＲＢＡＣ中，角色作为一个桥梁，沟通于用户和资源之间。对用户的访问授权转变为对角色的授权，然后再将用户与特定的角色联系起来。一县一个ＲＢＡＣ系统建立起来以后，主要的管理工作即为授权或取消用户的角色。ＲＢＡＣ的另一优势在于：系统管理员在一种比较抽象且与企业通常的业务管理相类似的层次上。根据ＮＩＳＴ在２００２年一月份的一份调查报告（ＴｈｅｏｆＲｏｌｅ—ＢａｓｅｄＡｃｃｅｓｓＥｃ０ＲＯＩｌｌｉｃＩｍｐＥｒｅｔＣｏｎｔｒ０１），分析了ＲＢＡＣ的诸多优点以及实施ＲＢＡｃ所产生的经济效益统计分析，得出如下结论：●ＲＢＡＣ从投入到公司／企业应用，到从ＲＢＡＣ带来的好处中获益，根据公司的大小不同，需要１到３个季度：这段期间是ＲＢＡＣ与旧系统的合并与融合期；・ＲＢＡＣ的ＮＰＶ（１３ｅｔｐｒｅｓｅｎｔｖａｌｕｅ，净产值）是实施ＲＢＡＣ的成本的６９倍到ｌ５８倍；・ＲＢＡＣ的ＩＲＲ（ｉｎｔｅｒｎａｌ到９０％；ｒａｔｅｏｆｒｅｔｕｒｎ．内部收益率）是３９％从上可以看出，其中蕴藏的商机是巨大的。尤其随着国家电子政务的推行，政府机构的办公自动化程度、企业信息化程度的提高，在政府、金融、卫生保健等领域，ＲＢＡＣ将有越来越广阔的应用发展前景。基于角色的访问控制【ＲＢＡＣ）及应用研究１４立项背景及目的基于上面的分析．我们觉得ＲＢＡＣ的研究和开发有重要的意义，因此电子科大一卫士通联合实验室与成都卫士通合作开发此项目，旨在针对ＲＢＡＣ的理论模型进行研究，同时对ＲＢＡＣ与典型应用结合中的关键技术进行分析和研究，以开发基于ＲＢＡＣ的应用产品。１．５ＲＢＡＣ项目的目标和主要研究内容项目目标是研究基于角色的访问控制的理论模型，掌握ＲＢＡＣ的基本思想和原则，为网络应用设计角色授权管理、验证工具，提供方便易用的二次编程接口，并结合实际中的典型应用如Ｗｅｂ应用、Ｅｍａｉｌ、数据库应用等．将ＲＢＡＣ技术用于网络应用中的访问控制，解决ＲＢＡＣ的应用问题中所涉及到的系列关键技术。主要研究内容包括：（１）理论研究・研究ＲＢＡＣ的理论模型，掌握其用户一角色一资源的核心实质。・根据对访问控制基本规则和完整性约束的研究、结合具体实际，确定ＲＢＡＣ规则集；（２）具体设计及实现●采用面向对象的技术设计数据对象。●根据规则集，设计方便易用的用户角色管理工具。・资源的采集和表示是一个要突破的关键技术，分析资源的表示和存储方法，将数据的存储抽象出来，与具体的实现无关，设计出方便易用的贽源管理工具。・设计基于角色的授权管理工具。・设计基于角色的访问控制的框架，以实现用户的管理、角色的管理、角色的资源授权、验证。（３）与应用结合：・使用并发处理技术，设计ＡＣＤＦ（ＡｃｅｓｓＣｏｎｔＦＯｌＤｅｃｊｓｊｏｎＦｕｎｃｔｉｏｎｓ）二次编程接口，为应用提供方便、灵活、易用、易维护的接口。・遵循设计模块化和可扩展的原则，针对具体应用设计ＲＢＡＣ与应用结合的方案。基于角色的访问控制（ＲＢＡＣ）及应用研究１．６本文的章节安排第一章，引言。主要介绍课题的来源和背景、ＲＢＡＣ的国内外研究动态、访问控制技术、项目的研究内容以及文章的章节安排等。第二章，ＲＢＡＣ的理论研究包括ＲＢＡＣ的核心和模型，由此引出后面ＲＢＡＣ的设计和实现。第三章，ＲＢＡＣ的设计和实现，包括ＲＢＡＣ为用户提供的一系列１二具和为用户提供的访问控制决定模块，以及实现所采用的关键技术，为后面的应用奠定基础。第四章，根据ＲＢＡＣ的设计，引出几个典型的应用。第五章，论文总结与工作展望。总括全文，指出本文的不足之处，并指出了系统设计和开发工作的不足以及解决方案。１．７本章小结本章介绍了ＲＢＡＣ的国内外研究动态、在实际中的应用和价值、项目立项背景、研究的目标和内容、访问控制技术以及全文的章节安排。下一章将ＲＢＡＣ的理论研究进行阐述。基于角色的访问控制（ＲＢＡＣ）及应用研究第二章ＲＢＡＣ理论研究２．１ＲＢＡＣ的基本概念２．１，１ＲＢＡＯ内核ＲＢＡＣ内核包含了ＲＢＡＣ最重要的方面。ＲＢＡＣ最基本的概念是分配给角色的用户，分配给角色的权限，用户通过成为角色成员获得权限。ＲＢＡＣ内核中，用户与角色、权限与角色的映射关系是多对多的映射关系。就是说同样的用户可以分配许多角色，并且单～的角色可以有很多用Ｊ。，同样的，对权限来说，同一个权限可以分配给许多角色，单～的角色可以赋予很多权限。ＲＢＡＣ内核还包含用户被指派相关角色过程的检查，即我们凭什么决定将角色赋予一个指定的用户或者将用户被指派给特定的角色。类似的对于角色被赋予相关权限的检查同样作为一个高级检查功能。ＲＢＡＣ内核包括用户会话的概念，即允许角色的激活和撤销激活，最后，ＲＢＡＣ内核还包括用户可以同时操作不同角色的权限。这就排除了对于用户只能在同一时间激活成一个角色的限制。ＲＢＡＣ内核抓住了操作系统一直以来执行的基于组的访问控制的典型特点，现在已经成为了常见的一种技术，ＲＢＡＣ内核的这些特性对于任何形式的ＲＢＡＣ都可以揭示其本质。ＲＢＡＣ内核主要定义了决定要排除的特性，这个建议标准定义了ＲＢＡＣ内核的一个最小特性集。尤其这些特性适合于传统的基于组的访问控制。不是每一种基于用户组的访问控制机制都适于放在内核中，对于ＲＢＡＣ内核来说忽略了角色被赋予相关权限的检查，尽管这个检查很重要，但是对于很多被广泛接受的ＲＢＡＣ系统来说都不提供这个特性。对于用户被指派并且同时可以被激活成多个角色的要求适合于我们有很多种变化大的角色，成千上百个，可能不适合于很少的角色，因此毫不置疑被认为对一个核心模型来说是这个要求太高了。定义核心模型的目的就是希望在标准化发展过程中定义一个比较精简的内核模型。基于角色的访问控制（ＲＢＡＣ）及应用研究２．１．２ＲＢＡＯ等级ＲＢＡＣ等级要求支持角色等级。等级定义了角色之间的资历关系，在数学上是一种偏序关系，上级角色可以获得他们的下级角色的权限，Ｆ级角色获得上级角色的成员资格，这个标准认可两种类型的角色等级。ＲＢＡＣ等级分为以下两种情况：（Ｉ）一般的等级ＲＢＡＣ，在这种情况下，支持任意一种角色层次的偏序关系，包括权限和用户资格的多继承。（２）受限制的等级ＲＢＡＣ。一些系统会在角色层次上强加一些限制条件，一般情况下，级别层次会被限制成树型结构或者倒叉树的结构。角色之间通常会有重叠，即属于不同角色的用户可能被赋予相同的权限。并且，在许多组织中，有大量的通用的权限被许多用广１使用，为了提高效率和支撑组织结构，ＲＢＡＣ明显包括了角色等级的概念，ＩＣＢＡＣ等级是除了ＲＢＡＣ内核之外的最重要的特性。静态职责分离一用于解决利益冲突的一种强制措：晦，在基于角色的系统中，利益冲突表现为一个用户获得了两个相互冲突的角色的权限。一种阻止这种利益冲突的的办法是静态职责分离，就是说对于用户被指派角色的过程强加约束条件。一个静态约束的例子就是两个互斥的角色。比如，一个角色是费用支出另一个是要监督这个费用支出的，组织禁止同一个用户被赋予互斥的角色，ＳＳＤ（ＳｔａｔｉｃＳｅｐａｒａｔｉＯＤｏｆＤｕｔＹ）策略可以在管理中心制定并统一实施，由于关于静态职责分离和角色继承关系上的潜在矛盾，不论角色层次存不存在，我们认为静态职责分离策略是必须的。ＳＳＤ一静态职责分离根据静态职责分离的规则，一个用户一旦被指派某个角色那么就不会成为另外一个角色或更多的其他的角色。角色层次存在时，派生的角色同样也要考虑执行这个限制条件。可以用（角色集，Ｆ１）来描述ＳＳＤ规则，即用户不能分配在这个定义的角色集超过ｎ个以上的角色，例如，一个用户不能在指定的角色集里面赋予全部角色，而这种强加的特性限制用户不能同时分配两个或多个角色。ＤＳＤ（ＤｙｎａｍｉｃＳｅｐａｒａｔｉｏｎｏｆＤｕｔｙ）一动态职责分离，同ＳＳＤ关系一样，限制用户的操作权限，然而ＤＳＤ不同于ＳＳＤ，通过上下文来强加这种限制，这种限制仅仅考虑用户被激活的角色之间的相互关系（即激基于角色的访问控制（ＲＢＡＣ）及应用研究活的角色是否相互互斥）．ＤＳＤ关系也定义了一个关系对，（角色ｓｅｔ，ｎ），ｎ大于等于２，表明，在这个角色集里用户不能激活担任ｎ个角色。ＤＳＤ属性使最小特权的原则得到扩展，每个用户在不同的时期有不同层次的权限，主要根据执行的任务来确定权限，这就保证了权限在规定的时间内执行相关的职责。这种最小特权原则称为“信任及时撤销”，权限的动态撤销如果没有动态分离机制那么将是一’个复杂问题，过去为了方便考虑通常被忽略了。ＳＳＤ解决利益冲突是通过在一个特定时间用户只能被赋予瓦斥角色中的一个角色来实现，ＤＳＤ允许用户被赋予不只一个角色，但是互斥的角色在各自独立工作不会导致利益冲突，只有在同时被激活时会产牛策略问题。尽管可以通过静态职责分离来满足职责分离要求，但是动态职责分离为企业提供了更高的效率和操作上的灵活性。２．２基于角色的访问控制参考模型ＮＩＳＴＲＢＡＣ模型根据四个模型组件来定义的，ＲＢＡＣ内核，ＲＡＢＣ等级，静态职责分离和动态职责分离。ＲＢＡＣ内核定义了ＲＢＡＣ元素的最小集合，包括元素集、关系，还包括用户与角色赋值关系、权限与角色赋值关系，除此之外，ＲＢＡＣ内核引入了角色激活的概念，ＲＢＡＣ内核是在任何ＲＢＡＣ系统中需要的，但是其他的组件是各自独立的，并且可能独自实施。ＲＢＡＣ等级组件支持角色层次。ＲＢＡＣ等级定义数学上的偏序关系，角色间的角色资历关系，为干１‘么上级角色可以获得下级角色的权限，下级角色可以获得上级角色的成员资格，除此之外，等级ＲＢＡＣ走出了简单的用户、权限同角色这种简单的赋值，引入了授权用户和权限的角色集概念。第三个模型组件，ＳＳＤ，增加了关于用户分配角色的互斥关系，由于ＳＳＤ关系和角色层次继承的潜在矛盾，ＳＳＤ模型组件定义了角色等级存在和不存在时的角色互斥关系。第四个组件，ＤＳＤ定义了用户对话中被激活的角色的互斥关系。每个模型组件包括下列子组件（１）基本元素组件（２）元素集之间的关系（３）功能表重要的是要注意ＲＢＡＣ参考模型定义了ＲＢＡＣ特性的分类法，这些特基于角色的访问控制（ＲＢＡＣ）及应用研究性可以组成很多的特性包，虽然试图定义ＲＢＡＣ特性的完整集合，但是模型关注的是提供标准术语定义许多显著的特性，表现在已有的模型和已经实施的商业产品中。２．２．１ＲＢＡＣ内核组件ＲＢＡＣ核心的模型元素集以及相互关系如图２—２所示，包括五种基本的数据：用户，角色，主体，操作，权限。ＲＢＡＣ核心包含了’一系列的会话，会话是一种用户和激活的角色子集之间的映射。用户的定义：是一个人，也可以拓展定义成机器、网络、聪明的代理，为简单起见，本文中的用户指人。角色的定义：是一种组织中关于权利和职责的工作的功能，通过分配角色授予给用户。权限的定义：一种ＲＢＡＣ保护下的客体的操作的认可。操作的定义：一个程序可操作的反映。这种ＲＢＡＣ控制的操作和客体根据系统要执行的类型而定。比如，一个文件系统，操作包括读、写、执行；在一个数据库管理系统中，操作包括插入、删除、添加、更新。任何一种访问控制机制的目的是为保护系统资源。然而，为了将ＲＢＡＣ用到计算机系统中，我们将资源称为保护客体。为了和早期的访问控制系统模型兼容，一个客体是一个包含或接收信息的实体，为实现ＲＢＡＣ系统，客体可以代表信息容器比如，操作系统中的文件和目录，数据库系统中的列、行、表以及示图，客体可以代表可以耗尽的系统资源，包括打印机、硬盘、ＣＰＵ时钟周期。ＲＢＡＣ的重点是角色关系，图２—１描述了用户赋值和权限赋值之间的关系。这个箭头表示一个多对多关系，一个用户可以赋给一个或多个角色，一个角色可以赋给一个或多个用户，这种安排提供了为权限到角色的分配和用户到角色的分配中提供了灵活性和粒度。基于角色的访问控制（ＲＢＡＣ）及应用研究圈２—１ＲＢＡＣ内核模型每一种对话是一个用户和多个角色的映射，一个在用户被激活成角色的子集的过程中用户建立了一个会话，每个会话与…个单独用户相关，每个用户与一个或多个对话有关。会话一角色的功能使用户被会话激活，用户一会话功能提供了与用户有关的会话集。用户的权限和赋予角色的权限都是通过用户会话激活的。２．２．２ＲＢＡＣ等级及模型这个模型引入了角色等级如图２—２所示。角色作为一个ＲＢＡＣ模型的关键方面，通常作为ＲＢＡＣ产品提供。等级是一个构建角色的自然过程，反映了组织的职责和权利。级别划分图２－２ＲＢＡＣ等级模型角色等级定义了角色之间的继承关系，继承关系根据权限被描述成：假如ｒ１包含ｒ２的所有权限，ｒ１继承ｒ２。这个标准认识到一般和受限的角色等级，一般的角色等级的ＲＢＡＣ提供了任意一种偏序的角色等级关系，包括权限和用户成员资格的多继承关系。受限的角色等级的ＲＢＡＣ可能是一个简单的树型结构（一个角色可能有很多的前辈，但是只有一个直接的子孙）比如倒叉树，注意用户成员资格的继承是自上至下的如图２—３，而角色权限是自下而上的如图２—４。基于角色的访问控制（ＲＢＡＣ）及应用研究？／／７、＼、一、＼，／／＼，＼／＼质量工程师ｌ开发工程师质量工程师２开发工程师２图２－３倒叉树结构质量工程师ｌ开发工程师１质量工程师２开发工程师２／，工程１部项目２部工程邵‘图２－４树型结构’（１）一般的角色等级。一般的角色等级支持多继承的概念，允许从两个或更多的角色资源遗传权限，或者继承用户成员资格。多继承提供了重要的等级树型，第一就是从多个下属角色组成一个角色，定义的角色和关系正好是组织和商业结构的特征（角色已经划分）。第二，多继承提供了用户／角色指派关系和角色间继承关系的处理上的统一。（２）受限的角色等级限制只有一个直接的后代子孙，尽管不支持多继承，他们通过ＲＢＡＣ内核仍然具有清晰的管理优势。ＲＢＡＣ约束将职责分离加入ＲＢＡＣ模型。职责分离关系用于强制解决政策的冲突，组织可能会用于预防用户行使超出范围的权力。作为一个安全原则，ＳＯＤ（Ｓｅｐａｔａｔｉ０ｒｌｏｆＤｕｔＹ）在工业、商业、政务行业中得到广泛的应用，目的是为了防止组织内的勾结。为了缩小这种可能性，有不同技能和不同兴趣的人被指派了不同的任务，这样町以防止阴谋和诈骗。ＲＢＡＣ标准里面允许静态职责分离和动态职责分离。静态职责分离：只有当～个角色与用户所属的其他角色彼此不互斥时，这个角色才能授权给该用户。动态职责分离：只有当～个角色与一主体的任何一个当前活跃角色都不互斥时，该角色才能成为该主体的另一个活跃角色。基于角色的访问控制（ＲＢＡＣ，及应用研究２，３本章小结本章对ＲＢＡＣ的概念和模型进行了阐述，对ＲＢＡＣ的核心组件和模型有了一定的了解．，以便进入下一章关于ＲＢＡＣ的设计和实现。４基于角色的访问控制（ＲＢＡＣ）及应用研究第三章ＲＢＡＣ设计和实现３１设计思想ＲＢＡＣ的设计思想包括：（１）以角色作为访问控制的主体用户以什么样的角色对资源进行访问，决定了用户拥有的权限以及可执行何种操作。所以在ＲＢＡＣ中，访问的主体变成了角色。（２）角色继承为了提高效率，避免相同权限的重复设置，ＲＢＡＣ采用了“角色继承”的概念，定义了这样的一些角色，它们有自己的属性，但可能还继承其他角色的属性和权限。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。（３）最小权限原则所谓最小权限原则是指：用户所拥有的权力不能超过他执行工作时所需的权限。实现最小权限原则，需分清用户的工作内容，确定执行该项工作的最小权限集，然后将用户限制在这些权限范围之内。在ＲＢＡｃ中。可以根据组织内的规章制度、职员的分工等设计拥有不同权限的角色，只有角色需要执行的操作才授权给角色。当一个主体预访问某资源时，如果该操作不在主体当前活跃角色的授权操作之内，那么该访问将被拒绝。（４）职责分离对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这些操作。“职责分离”可以有静态和动态两种实现方式。静态职责分离：只有当～个角色与用户所属的其他角色彼此不互斥时，这个角色才能授权给该用户。动态职责分离：只有当一个角色与一主体的任何一个当前活跃角色都不互斥时，该角色才能成为该主体的另一个活跃角色。（５）角色容量（基数）在创建新的角色时，要指定角色的容量。在一个特定的时间段内，有一些角色只能由一定人数的用户占用。（６）ＲＢＡＣ的优势基于角色的访问控制（ＲＢＡＣ）及应用硼究ＲＢＡＣ盼最失优势在于它对授权管理的支持。通常的访问控制实现方法将用户与访问权限直接相联系，当组织内人员新增或有人离开时，或者某个用户的职能发生变化时，需要进行大量授权更改工作。而在ＲＢＡＣ中，角色作为一个桥梁，沟通于用户和资源之间。对用户的访问授权转变为对角色的授权，然后再将用户与特定的角色联系起来。一旦一个ＲＢＡＣ系统建立起来以后，主要的管理工作即为授权或取消用户的角色。ＲＢＡＣ的另一优势在于：系统管理员处在一种比较抽象且与企业通常的业务管理相类似的层次上。总之，基于角色的访问控制的基本思想是：根据用户的职权，分配给每个用户一些合适的角色，每～个角色都具有其对应的权限，角色是安全控制策略的核心。３．２设计原则在本系统的设计中，ＲＢＡＣ中的基本规则如下：（１）如果一个用户不具有任何角色，那么该用户无权执行任何操作。这一规则保证任何用户只有通过角色才能完成其功能，而不能绕过角色直接访问客体。（２）主体的活动角色必须是经过授权的。规则２在规则１的基础ｊ二确保用户只能扮演经过授权的角色。（３）如果某主体要执行某个事务．那么该事务必须是授给该用户的当前活动角色的。在规则１和规则２的基础上，规则３确保用户只能执行经过授权的事务（操作）。本系统中的ＡＣＤＦ（ＡｃｃｅｓｓＣｏｎｔｒｏｌＤｅｃｉＳｉＯｎＦｕｎｃｔｉＯｎＳ）模块就是基于上面的三条规则进行判断的。为了控制系统的复杂性，保证系统的可实现性。本系统在设计时，对于ＲＢＡＣ的规则作了相关的取舍。本系统没有设计动态互斥。下面是本系统实现所基于的规则列表：规则１：每个角色的授权用户数不能超过其基数（ＣａｒｄｉｎｇｌｉｔＹ）：规则２：角色自己不能继承自己；规则３：两个静态互斥的角色不能被赋予给同一用户；规则４：每个角色不能与自己静态互斥；规则５：静态互斥是具有对称性的；规则６：一个角色只能拥有一个父角色，即禁止多继承；规则７：禁止循环继承，即一个角色不能通过多层继承到自己；基于角色的访问控制（ＲＢＡＣ）及应用研究规则８：角色定义不能重复；规则９：继承关系定义不能重复；规则１０：互斥关系定义不能重复；规则１１：用户的活动角色只能是用户所拥有的角色的一个子集。规则１２：每个角色的派生角色基数之和加上该角色己分配用户数之和不应当超过该角色基数。３．２．１角色基数控制角色基数控制主要在ＲＢＡＣ规则１和规则１２中进行了描述，ＡｄｄＡＳＳｉｇｎｍｅｎｔ（ｕＳｅｒ，ｒｏｌｅ）（为用户分配角色）和ＡｄｄＩｎｈｅＦｉｔａｎｃｅ（）（添加继承关系）两个操作涉及到角色基数控制。下面进行了角色基数控制的规则描述和操作中涉及到角色基数控制的流程。规则描述：（１）规则（ＣａｒｄｉｎａｌｉｔＹ）：ｌ：每个角色的授权用户数不能超过其基数Ｖｒ∈ＲＯＬＥＳ＝，Ｊａｕｔｈｏｒｉｚｅｄ—ｕｓｅｒｓ（ｒ）Ｉｓｃａｒｄｉｎａｌｉｔｙ（ｒ）（２）规则１２：每个角色的派生角色基数之和加上该角色已分配用户数之和不应当超过该角色基数：ＶｒＲｏｌｅｓ，Ｖ‘ＥＲＯＬＥＳ，‘－＇，ｊ｛∑．ｃａｒｄｉｎａｌｉｔｙ（ｒ，）＋ｌａｓｓｉｇｎｅｄ～ｌｇＳＰｒｓ（，）Ｊ｝≤ｃａｒｄｉｎａｌｉｔｙ（ｒ）３．３关于设计的说明３．３．１动态互斥（动态职责分离，ＤＳＤ）先说明静态互斥。静态互斥保证下面的情况不会出现：同一个用户被赋予本来不应该由～个人拥有的两个角色。举个简单例子，财务ｆ：的出纳和会计，不能由～个人兼任，当使用ＲＢＡＣ对用户赋予权限的时候，就不能让一个人同时拥有出纳和会计的角色。这个功能可以留给管理员来负责，由他自己来保证互斥角色不能赋予同一个人。ＲＢＡＣ加入瓦斥逻辑后，就能帮助管理员，让他永远不会犯这种错误。丽动态互斥则是在静态互斥的概念上加入了扩展，它引入了“活动基于角色的访问控制（ＲＢＡＣ）及应用研究角色”的概念。当用户的一个角色是“活动”的时候，它就可以行使这个角色拥有的权力：而当这个角色是“非活动”的时候，就暂时不能行使这个角色的权力。这样，一个用户就可以同时拥有互斥的两个角色，前提是这两个角色不能同时是“活动”的。举个例子，在财务上，由出纳主管来负责监视出纳员打开收银柜的行为是否合法，这样，一个人不能同时是出纳员和出纳主管。但是，在实际情况下，有的人既是出纳主管，又兼有出纳员的工作，这怎么办昵？当引入了动态百斥的概念后，一个用户可以被同时授权为出纳员和出纳主管，如果该用户在使用出纳的角色时，想要转为使用出纳主管的角色，ＲＢＡＣ将要求该用户退出其出纳的角色，并因而要求该用户在行使出纳主管角色之前先关闭收银柜。只要用户不能在同一时刻拥有这两个角色，利害冲突就不会出现。由上面分析可见，互斥功能是对管理员操作的一种帮助，如果管理员自己能保证互斥的角色不会被赋予到同一个人，互斥功能就没有意义（考虑到角色的继承，如果两个角色互斥，继承这两个角色的角色也瓦斥，有时管理员真的不能理清哪些角色之间有互斥关系）；而动态互斥是对静态互斥的一种补充，它填补了静态互斥的一些例外情况。实际工作中，如果一个人就是被赋予了互斥的角色．但互斥角色不同时作用，在这样的情况下，动态互斥就能避免出现静态互斥不能处理，而出现的角色不能正确配置的尴尬局面。目前的项目中之所以没有引入动态互斥，有两个方面的考虑：（１）一个人给赋予互斥角色的可能性小。比如，财务管理中，‘一般／卜会让出纳和会计由同一个人担当。实际上，这种互斥角色的存在，就是因为一旦互斥角色由同一个人拥有，可能会出现比较严重的后果。管理上尚且不能允许，通过软件就更加难于控制。（２）引入动态互斥，必然引入活动角色的概念。这样在用户拥有的每个角色数据中，要增加“是否活动”字段，于是在几乎所有处理用户和角色的程序中，都需要加入处理“是否活动”的代码。同时，对动态互斥的逻辑引入，对活动角色的一致性检查，这些都不是短期就能完成的。因此，基于对开发时间和功能所产生的作用的衡量，我们决定在当前版本中不引入“动态互斥”的功能。３．３．２多继承（ＭｕＩｔｉＰＩｅＩｎｈｅｒｉｔａｎｃｅ）在ＲＢＡＣ中，多继承关系包含两方面的含义基于角色的访问控制（ＲＢＡＣ）及应用研究（１）一个角色可以有多个子角色；（２）一个角色可以从多个角色继承。从一个角色的观点看，这实际上是两个方向上的继承。我们只实现了第一条，没有实现第二条。也就是说，在我们的ＲＢＡＣ中，～个角色可以有多个子女，但只能有～个父亲。如果一个角色有多个父母，在实际情况中的表现是：一个角色同时拥有不同的两个角色的权限集。比如，总经理应该具有所有部门经理的权限，这样总经理角色只需要从所有的部门经理角色中继承权限，就可以形成总经理角色的权限。在ＲＢＡＣ标准中，继承包含“一般继承”和“受限”继承，受限继承就是我们目前实现的功能。受限继承的优点是角色集是一个树状结构，比较明确；如果使用一般继承，角色就不是树状了。一个角色可以继承多角色的能力，这主要为了方便配置；如果没有这个能力，角色权限的赋予同样可以完成。因此，不实现对功能没有什么影响，只对操作有影响。两且实际情况下，一个角色可以继承多角色并不常见。并且通过分析发现，实现个角色继承多角色的功能，将大大增加程序设计的复杂度，综合考虑，我们暂不把该功能加到当前设计的系统中去。３，４ＲＢＡＣ体系结构本系统支持传统的Ｂ／Ｓ、Ｃ／Ｓ应用（ｗＥＢ应用），支持Ａｐａｃｈｅ、¨Ｓ５２ＥＥ三种典型应用（占ＷＥＢ应用９０％以上）。体系结构如图３—１。基于角色的访问控制（ＲＢＡＣ）及应用研究浏览器应用程序ｂＡ篙一ｂ篡。，一ｂ’蒹，一１广一—－Ｆ３ＲＢＡＣ管理～访问控制信息？一虚拟资源信息ＡＣＬ信息服务躺１上１上一数据库资源收集模块图３－１ＲＢＡＣ总体结构图Ａｐａｃｈｅ、ＩＩＳ、Ｊ２ＥＥ的Ｆｉｌｔｅｒ中提供了应用接口，能够对资源访问请求进行预处理。本系统主要通过Ａｐａｃｈｅ、ＩＩＳ、Ｊ２ＥＥ的Ｆｊ】ｔｅｒ中在ＲＢＡＣ设计中，将资源授权和受保护资源脱离开来，在ＡＣＬ信息资源的收集工作也是系统设计的一个重要方面，随不同应用收集方法也不相同，将在下面的模块设计中会有详细的描述。３．５ＲＢＡＣ系统基本功能模块ＲＢＡＣ系统包含的功能模块：（１）可视化角色编辑工具（２）用户授权管理工具（３）ＵＲＩ（ＵｎｉｆｉｅｄＲｅＳｏｕｒｃｅＩｎｄｅｎｔｉｔＹ）权限管理工具（４）ＲｂａｃＡｃｄｆ测试工具（５）Ｒｂａｃ目志管理工具（６）ＲｂａｃＡｄｍｉｎ集成管理工具（７）ＵＲＩ列表生成工具ＵＲＩＧｅｎｅｒａｔｏｒ各模块在网站上的应用部署如图３—２所示：２０加入身份认证模块和访问控制模块，通过对请求访问的资源的授权判断，达到对系统资源的保护。服务器上建立资源的虚拟镜象，对镜象资源进行授权。这样避免了授权管理人员接触用户的敏感信息，从而对资源实施最有效的保护。因此，基于角色的访问控制（ＲＢＡＣ）及应用研究图３－２网站应用ＲＢＡＣ系统对服务端的要求如下：需要一台操作系统为ｗｉｎｄｏｗｓ２０００的机器来安装ＲＢＡＣＡｄｍｉｌ３集成管理工具，管理员可以定义整个公司的角色、为用户授权、以及管理Ｗｅｂ服务器上的目标资源的权限；需要一台机器来安装ＭＹＳＱＬ数据库，存放所有角色及权限数据；Ｗｅｂ服务器上安装ＲＢＡＣ的ＡＣＤＦ模块（可以根据不同的Ｗｅｂ服务器，安装不同的ＡＣＤＦ模块）。ＲＢＡＣ系统本身对客户端不作更多的要求。３．５．１可视化角色编辑工具图３—３为可视化角色编辑工具的界面。图３－３可视化角色编辑工具可视化的角色编辑工具是本系统中的一个重点，因为角色之间的关系高度抽象，如果不以可视的图形方式直观地显示和编辑的话，会给用户的理解和使用带来很大的障碍。在角色编辑过程中，要保证角色定义、基于角色的访问控制（ＲＢＡＣ、及应用研究继承关系、互斥关系和角色基数的一致性和完整性。其功能包括：定义角色属性；定义角色之间的派生关系；定义角色之间的静态互斥关系：确保角色与相关关系定义的完整性与一致性；避免角色基数产生冲突；可视化操作功能；操作可回退与可重复。这些操作均得益于采用了可视化而变得简单而直观。３．５．２用户授权管理工具图３—４为用户授权管理工具的界面：图３—４用尸授权管理工具用户通过与拥有特定权限的角色关联，从而拥有该角色所拥有的权限，这是ＲＢＡＣ的用户管理工具的理论基础。所以对用户进行权限管理，实际上就是对用户与角色的关系进行管理。本工具提供了对用户进行角色赋予和撤消的操作，并保证数据的一致性和完整性，以达到权限管理的目的。３．５．３ＵＲｌ权限管理工具图面。０Ｊ—５为ＵＤｎＩ（Ｕｎ．１ｉＰＬ．１１ｅｄＲｅＳＯＵｒＣｅ【ｎ，０ｅｎｔ１ＬｔＶ，）权限管鳇工且一的界基于角色的访问控制（ＲＢＡＣ）及应用研究图３－５ＵＲＩ权限管理工具本系统以Ｗｅｂ应用为目标应用，因此ＲＢＡＣ访问控制系统所管理的对象就是ｕＲＩ。在系统的设计中，已将控制粒度细化到ｕＲＩ一级，本工具就是用来对ＵＲＩ进行权限管理，为角色分配操作权限。３．５．４ＲｂａｃＡｃｄｆ测试工具图３－６为ＲＢＡＣＡｃｄｆ测试工具的界面。图３－６ＲＢＡＣＡｃｄｆ测试工具对ＲＢＡＣＡｃｄｆ进行模拟测试，以便帮助管理员更好的配置ＲＢＡＣ服务。３．５．５Ｒｂａｃ日志管理工具图３—７为ＲＢＡＣＡｃｄｆ日志管理工具的界面。２３基于角色的访问控制（ＲＢＡＣ）及应用研究图３－７ＲＢＡＣ日志管理工具用来管理ＲＢＡＣ日志，为配置更优化的ＲＢＡＣ服务提供参考。３．５．６ＲｂａｃＡｄｍｉｎ集成管理工具为了使用方便，将上述的１至５项工具集成到一个管理工具中以便统一管理。图３—８为ＲＢＡＣＡｄｍｉｎ集成管理工具的界面。图３－８ＲｂａｃＡｄｍｉｎ集成管理工具３．５．７ＵＲＩ列表生成工具ＵＲＩＧｅｎｅｒａｔｏｒｕＲＩ列表生成工具用于将磁盘中的文件转变为对应的ｕＲＩ资源列表。图３—９为ＵＲＩ列表生成工具的界面。２４基于角色的访问控制（ＲＢＡＣ）及应用研究图３—９ＵＲＩ列表生成工具３．６ＲＢＡＣ二次开发接口一访问控制决定模块ＲＢＡＣ－－次开发接口提供访问控制决定功能的调用，可用于ＩＪＳ服务器端脚本，以及各种应用程序，可以是ＣＯＭ控件，也可以是二次开发包。３．６．１接口说明（１）初始化ＡＣＤＦ环境的函数：ｅｘｔｅｒｎ”Ｃ”ｖｏｉｄ￥ＦＡＲＰＡＳＣＡＬＥＸＰＯＲＴｄ１１一ＲｂａｃＡｃｄｆＩｎｉｔ（）；在现行版本中，用此函数初始化ＡＣＤＦ环境，执行连接数据库的动作。（２）执行ＡＣＤＦ的函数：ｅｘｔｅｒｎ”Ｃ”ｉｎｔＣ０ｎｓｔｃ０１３ＳｔｃｏｌｌｓｔＦＡＲＰＡＳＣＡＬＥＸＰＯＲＴｄ１１一ＲｂａｃＡｃｄｆ（ｃｈａｒ｝ＵＳｅｒＮａｍｅ，ｃｈａｒ｛ＤｅｓｔＵＲＩ，ｃｈａｒ｝ＯｐｅｒＴｙｐｅ，ｃｈａｒ￥ｓｔｒＴｅｍｐ，ｖｏｉｄ￥ｐａｒ）：参数说明：前三个参数很好理解，ｓｔｒＴｅｍｐ传出执行结果描述，ｐａｒ传入经初始化的指针。返回值说明：若成功，返回０；否则返回非０值。（３）关闭ＡＣＤＦ环境的函数：２５基于角色的访问控制（ＲＢＡＣ）及应用研究ｅｘｔｅｒｎ”Ｃ”ｖｏｉｄＦＡＲＰＡＳＣＡＬＥＸＰＯＲＴｄ１１一ＲｂａｃＡｅｄｆＣ］ｏｓｅ（ｖｏｉｄ＊ｐａｒ）；传入的参数是初始化得到的指针。（４）根据用户名获得角色列表的函数：ｅｘｔｅｒｎ”Ｃ”ｉｎｔＦＡＲＰＡＳＣＡＬＥＸＰＯＲＴｄ１１ＧｅｔＲ０１ｅＬｉＳｔＯｆＡＵｓｅｒ（ｃｏｎＳｔＣｈａｒ木ＵｓｅｒＮａｍｅ，ｃｈａｔ＊ｓｔｒＴｅｍｐ）参数说明：ｕｓｅｒＮａｍｅ传入用户名，ｓｔｒＴｅｍｐ传出用户所具有的角色名（以”：”隔开）。返回值说明：成功，返回０；否则返回非０值。（５）判断资源是否受保护ｅｘｔｅｒｎ”Ｃ”ｉ１１ｔＦＡＲＰＡＳＣＡＬＥＸＰＯＲＴｄｌｌｉｆＲｅｓｏｕｒｃｅＰｒｏｔｅｃｔｅｄ（ｃｏｎｓｔｃｈａｔ宰ＤｅＳｔＦｉｌｅ）参数说明：ＤｅＳｔＦｉｌｅ需要判断的资源。返回值说明：资源受保护返回０，否则返回１３．６．２示倒程序（１）访问控制决定模块的示例：通过ｗｉｚａｒｄ新建一个支持ＭＦＣ的ＷｉｎｄｏｗｓＣｏｎｓｏｌｅ应用工程＃ｉｔＩＣｌｕｄｅ”．．＼＼ＲｂａｃＡｃｄｆＤｌｌ．ｈ”／／包含ＤＬＬ头文件ｃｈａｒ￥ｓｔｒＯｓｒＮａｍｅ＝”ＩＩＳＴ”：ｃｈａｒ堆ｓｔｒＤｅｓｔＵＲＩ”ｈｔｔｐ：／／ｗｗｗ．ａｂｃ．ｃｏｍ／ＯｂＪｅｃｔＭａｎａｇｅｒ．ｅｘｅ”ｃｈａｒ木ｓｔｒｏｐｅｒＴｙｐｅ＝”ｒｅａｄ”：ｃｈａｒｓｔｒＲｅｓｕｌｔ［２５６］：ｖｏｉｄ％ｐａｒ：ｐａｒ＝ｄｌｌ—ＲｂａｃＡｃｄｆＩｎｉｔ（）；ＣＯＵｔ＜＜ｓｔｒＵｓｒＮａｍｅ＜＜”＼ｔ”＜＜ｓｔｒＤｅｓｔＵＲＩ＜＜”＼ｔ”＜＜ＳｔｒＯｐｅｒＴｙＰｅ＜＜ｅｎｄｌ：Ⅱ１ｅｍＳｅｔ（ｓｔｒＲｅｓｕｌｔ，０，２５６）：｝／ｔｅＳｔｆｏｒＲｂａｃＡｃｄｆｉｎｔｉＲｅｓｕｌｔ＝ｄｌｌ—ＲｂａｅＡｃｄｆ（ｓｔｒＵｓｒＮａｍｅ，ｓｔｒＤｅＳｔＵＲＩ，ＳｔｒＯｐｅｒＴｙＰｅ，ｓｔｒＲｅｓｕｌｔ，ｐａｒ）：ＣＳｔｒｉｎｇｓｔｒＭｓｇ：ｓｔｒＭｓｇ．Ｆｏｒｍａｔ（”ＲｅｓｕｌｔＣｏｄｅ＝％ｄ，Ｍｓｇ２６墨量鱼鱼盟堕塑堡型！垦堡垒兰！墨壁旦堕塞％ⅣＳｅＵｌｔＳｔｒＤｎｅＳＵｌｔ）ＣＯＵ，ｔ．１＜Ｒ（”Ｓ＼ｎＡＣ，ＤＦ钡试Ｃｏｄｅ＝”＜＜ｉＲｅＳＵｌｔ＜＜。＼ｎＭｓｇ＝”＜＜ＳｔｒＲｅＳｕｌｔ＜＜ｅｎｄｌｄｌｌ～ＲｂａｃＡｃｄｆＣｌ０ｓｅ（ｐａｒ）；（２）获取用户角色的程序的示例：：／／ｃｅｓｔｆｏｒｇｅｔｒＯＩｅｓｆｒｏｍｕＳｅｒｃｂａｒ｝ＳｔｒＵＳｒＮａｍｅ＝”ＣＨＥＮＦＬＯｌ”：ｃｈａｒｓｔｒＲｅｓｕｌｔ［２５６］：ｍｅｍｓｅｔ（ＳｔｒＲｅＳｕｌｔ，０，２５６）：ｉＲｅｓｕｌｔ：ｄ１１一ＯｅｔＲ０１ｅＬｉＳｔＯｆＡＵＳｅｒ（ｓｔｒＵＳｒＮａｍｅ，ＳｔｒＲｅｓｕｌｔ）ｃｏｕｔ＜＜”＼ｎ用户身份测试：＼ｎＣｏｄｅ＝”＜＜ｉＲｅｓｕｌｔ＜＜”＼ｎＭｓｇ＝”＜＜ｓｔｒＲｅｓｕｌｔ：（３）判断资源是否受保护的示例：Ｃｈａｔ｝ＳｔｒＤｅＳｔＦｉｌｅ＝”ｈｔｔｐ：／／ｗｗｗ．ａｂＣ．ｃｏｍ／ＵＲＩＤｌｌＴｅｓｔ．ｅｘｅ”／／ｔｅｓｔｆｏｒｉｆＲｅｓｏｕｒｃｅＰｒｏｔｅｃｔｅｄｃｏｕｔ＜＜”ｋｎ资源是否受保护测试＼ｎ资源：”＜＜ＳｔｒＤｅｓｔＦｉｌｅ＜＜”保护代码：“（＜ｄ１１一ｉｆＲｅｓｏｕｒｃｅＰｒｏｔｅｃｔｅｄ（ｓｔｒＤｅｓｔＦｉ１ｅ）＜＜ｅｎｄｌ３。７ＲＢＡＣ实现的关键技术３．７．１ＲＢＡＯ信息数据抽象公共接口ＲＢＡＣ系统中，系统角色及相关信息都保存在ＬＤＡＰ服务器上，这样系统的可扩展性较差。现有系统准备采用这样的改进思想，提供数据存储的公共接口，如图３一１０，由用户提供公共接口的实现，按照用户自己的需求进行数据存储。２７基于角色的访问控制（ＲＢＡＣ）及应用研究图３—１０数据抽象存取接口在以前的数据存取中，采用的方式是存储数据到文件，然后将文件传送到ＬＤＡＰ服务器上，如图３—１ｌ。这种方式数据存储方式单一，并和管理工具紧密的绑定在一起，不能满足不同安全用户对数据存储的１ｉ同需求。如果，用户要添加新的数据存储方式，必须重新编译ＲＢＡＣ系统才行，这种方式也是行不通的。ＲＢＡＣ集成管理工具Ｉ［］．．．．．．．．．．．．一【．．．．．．．．．．．．．．．一数据仔取—一ｆ＜３Ｉ蛐良吼ｆＩ—ｌ图３－１１信息数据原有存储方式在新的管理系统中，提供了数据存储的抽象接口，由ＲＢＡＣ管理工具调用动态连接库的抽象存储接口进行数据的存储，如图３—１２，这样，用户就可以按照抽象存储接口实现数据存储打包，由系统启动时，通过配置文件加载，就可以按照用户的方式进行存储，而无须编译原来的系统。基于角色的访问控制（ＲＢＡＣ）及应用研究ＲＢＡＣ集成管理工具ｒ＿————］［］［］１．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．一图３．１２信息数据现有的存储方式系统主要提供角色信息、用户授权信息、用户名列表的存储功能，默认方式采用的是直接从数据库进行读取。信息数据接口包括的以下的内容：（１）角色文件抽象存取接口ＳｔｏＦｅＲｏｌｅＴｏＤＬＬ（角色信息的指针）／／１．调用签名函数进行签名／／２．写入角色信息）（方式可由用户自己提供）ＬｏａｄＲｏｌｅＦｒｏｍＤＬＬ（角色信息的指针）ｔ／／１．调用验证函数进行验证／／２．读取角色信息到内存结构）（方式可由用户自己提供）（２）可视化数据的存取接口ＳｔｏｒｅＲｏｌｅＭａｐＴｏＤＬＬ（角色可视化化数据信息的指针）｛／／１．调用签名函数进行签名／／２．写入角色的图元信息（方式可由用户自己提供）ＬｏａｄＲｏｌｅＭａｐＦｒｏｍＤＬＬ（角色可视化化数据信息的指针）｛／／１．调用验证函数进行验证／／２．读取角色图元信息到内存结构（方式可由用户自己提供））（３）用户授权信息的存取接口２ｑ基于角色的访问控制（ＲＢＡＣ）及应用研究ＳｔｏｒｅＵｓｅｒＡｕｔｈｏｒｉｔｙＩｎｆｏＴｏＤＬＬ（用户授权信息内存结构指针）／／１．调用签名函数进行签名／／２．写入用户的授权信息（方式可由用户自己提供）ＬｏａｄＵｓｅｒＡｕｔｈｏｒｉｔｙＦｒｏｍＤＬＬ（用户授权信息内存结构指针）／／１．调用验证函数进行验证／／２．读取用户授权信息到内存结构（方式可由用户自己提供））（４）用户名列表的存取ＳｔｏＦｅＯｓｅｒＬｉｓｔＴｏＤＬＬ（用户列表信息的指针）｛／／１．调用签名函数进行签名／／２．写入用户列表信息（方式可由用户自己提供）ＬｏａｄＵｓｅｒＬｉｓｔＤＬＬ（用户列表信息的指针）｛／／１．调用验证函数进行验证／／２．读取用户列表信息到内存结构（方式可由用户自己提供）｝信息数据存储过程及实现如图３—１３。一．垩主鱼鱼竺望塑塑型！垦呈垒曼！墨查旦堡壅初始化动态连接库获取动态连接库句柄调用动态连调用动态连调用动态连调用动态连接库角色存接库角色图接库用户授接库用户列取接口元存取接口权存取接口表存取接口签名，验证Ｉｌ签名，验证ｌＩ签名／验证ｌ｝签名／验证存取数据到存取数据到存取数据到内存结构＼存取数据到内存结构内存结构内存结构关闭动态连接库图３一１３信息数据存储过程及实现３．７．２ＲＢＡＣ信息数据存储接口概要设计３７２１动态连接库调用接口动态连接库名称：ｄａｔａｂａｓｅｓｔｏｒｅ．ｄｌｌ（１）用户名列表信息文件包括的接口：・存储用户名列表信息到数据库：ｉｎｔｓｔｏｒｅＵｓｅｒＴｏＤａｔａｂａｓｅ（ｃｈａｒ木ｕｓｅｒＬｉｓｔＤａｔａ）返回值＝一１：失败返回值＝０：成功●读入用户名列表信息：ｉｎｔ１０ａｄＵｓｅｒＦｒｏｍＤａｔａｂａｓｅ（ｅｂａｒ＊ｕｓｅｒＬｉｓｔＤａｔａ）返回值＝一１：失败返回值＝０：成功基于角色的访问控制（ＲＢＡＣ）及应用研究（２）角色信息文件包括的接口：・存储角色信息到数据库ｉ１３ｔＳｔｏｒｅＲｏｌｅＩｎｆｏＴｏＤａｔａｂａｓｅ（ｃｈａｒ＊ｒ０１ｅＣａｒｄＤａｔａ，ｃｎａｒ｝ｉｎｈｅｒｉｔＤａｔａ，ｃｈａｔ＊ＳｅｐＤａｔａ）返回值＝一１：失败返回值＝０：成功・从数据库读入角色信息文件ｉｎｔｌｏａｄＲ０１ｅＩｎｆｏＦｒｏｍＤａｔａｂａＳｅ（ｃｈａｒ￥ｉｎｈｅｒｉｔＤａｔａ，ｃｈａｒ＊ｓｅｐＤａｔａ）返回值＝一ｌ：失败返回值＝０：成功（３）角色图元信息文件包括的接口・存储角色图元信息到数据库ｉｎｔｓｔｏｒｅＲｏｌｅＭａｐＴｏＤａｔａｂａＳｅ（ｃｈａｒ＊ｒｏｌｅＭａｐＤａｔａ）返回值＝一１：失败返回值＝０：成功・从数据库中读入角色图元信息ｉｎｔｌｏａｄＲ０１ｅＭａｐＦｒｏｍＤａｔａｂａｓｅ（ｃｈａｒ＊ｒ０１ｅＭａｐＤａｔａ）返回值＝一１：失败返回值＝０：成功（４）用户授权信息包括的接口：●存储用户授权信息到数据库ｉｎｔｓｔｏｒｅｇｓｅｒＡｕｔｈｏｒｉｔｙＴｏＤａｔａｂａｓｅ（ｃｈａｒ＊ｕｓｅｒＡｕｔｈＤａｔａ）返回值＝一１：失败返回值＝０：成功・从数据库读入用户授权信息ｉｎｔ１０ａｄＵｓｅｒＡｕｔｈｏｒｉｔｙＦｒｏｍＤａｔａｂａｓｅ（ｃｈａｒ＊ｕＳｅｒＡｕｔｈＤａｔａ）返回值＝一１：失败返回值＝０：成功（５）执行用户名和授权信息的一致性检查ｉｎｔｃｈｅｃｋＣｏｎｓｉｓｔｅｎｃｙ（）返回值＝一１：返回值＝０：数据库操作失败成功，没有执行一致性更改成功，执行了一致性更改返回值＝１：基于角色的访问控制（ＲＢＡＣ）及应用研究３．７．２．２数据库及相关接口（１）数据库的建立数据库的初始化创建，在安装时就已经创建，包括两个数据源：ｒｂａｃａｄｍｉｌ３、ｒｂａｃ．一ｕｒｉ。ｒｂａｃａｄｍｉｎ数据源中创建的表：ｕｓｅｒｌｉＳｔ、１＂０ｌｅ—ｃａｒｄｉｎａｌｉｔｙ、ｒｏｌｅｉｎｈｅｒｉ￡、ｒｏｌｅｓｅｐ、ｒｏＩｅｍａｐｉｎｆｏ、ＵＳ｛３１ｆ＇一ａｕｔｈｏｒｉｔｙ、ａｄｍｉｎｕｓｅｒ。ｒｂａｃｕｒｉ数据源中创建的表：ｕＲＩＭｅｒａｄａｒａ、ＩＪＳｅｒ、ｔａｂｌｅｎａｍｅｌｉｓｔ、ＵＲＩｈｉｓｔＳａｍｐｌｅ、ａｃ上一ｌｉＳｔ、ｕｓｅＦ—ＦＯｌｅ。表的建立如下：ＤＩ｛ＯＰＤＡＴＡＢＡＳＥＩＦＥＸＩＳＴＳｒｂａｃａｄｍｉｎ：ＤＲＯＰＤＡＴＡＢＡＳＥＩＦＥＸＩＳＴＳｒｂａＣｕｒｉ：ＣＲＥＡＴＥＤＡＴＡＢＡＳＥｒｂａｃａｄｍｉｌｌ：ｕＳｅｒｂａｃａｄｍｉｒｌ：ＣＲＥＡＴＥＴＡＢＬＥｕＳｅｌ＂ｌｉｓｔ（ｕｓｅｒｌｉｓｔＶＡＲＣＨＡＩｉ（６４）ＮＯＴＮＵＬＬ，ＰＲＩＭＡＲＹＫＥＹ（ｕｓｅｒｌｉｓｔ））：ＣＲＥＡＴＥＴＡＢＬＥｒｏｌｅｃｏ．ｒｄｉｈａｌｉｔＹ（ｒ０１ｅｎａｌｌｌｅＶＡＲＣＨＡＲ（６４）ＮＯＴＮＵＬＬ，ＣａｒｄｉｎａｌｉｔＹＢＩＧＩＮＴＮＯＴＮＵＥＬ，ａｓｓｉｇｎｅｄＢＩＧＩＮＴＮＯＴＮＵＬＬＤＥＦＡＵＬＴ’０’）：ＣＲＥＡＴＥＴＡＢＬＥｒｏｌｅ—ｉｎｈｅｒｉｔ（ｐａｒｅｎｔ１３ａｍｅＶＡＲＣＩｔＡＩｉ（６４）ＮＯＴＮＵＬＬ，ｃｈｉ１ｄｒｌａｍｅＶＡＲＣＨＡＲ（６４）ＮＯＴＮＵＬＬ）：ＣＲＥＡＴＥＴＡＢＬＥｒｏｌｅｓｅｐ（ｒｏｌｅｒｌａ，ｍｅＶＡＲＣｔｔＡＲ（６４）ｔ＇ｊＯ＇ｒＮＵＬＬｓｅＰ１＂１ａｍｅＶＡＩ｛ＣＨＡＲ（６４）ＮＯＴＮＵｌ．Ｌ）：ＣＲＥＡＴＥＴＡＢＬＥｔ０１ｅ—ｍａｐｉｎｆｏ（ｒｏ】ｅｍａｐＩｎｆｏｒｍａｔｉ０１３ＶＡＲＣＨ，～Ｉ｛（２５Ｌｔ）ＮＯＴＮＵＬＬ基于角色的访问控制（ＲＢＡＣ）及应用研究ＰＲＩＭＡＲＹＫＥＹ（ｒＯｌｅｍａｐＩｎｆｏｒｍａｔｉＯｉｌ））：ＣＲＥＡＴＥＴＡＢＬＥＵｓｅｒａｕｔｈｏｒｉｔｙ（ＵＳｅｒｉｎ＿ａｍｅｖＡＲＣＨＡＲ（６４）ＮＯＴＮＵＬＬＦ０１ｅｎａｍｅＶＡＲＣＨＡＲ（６４）ＮＯＴＮＵＬＬＰＲＩＭＡＲＹＫＥＹ（ＵＳｅｒｒｌｓ，ｍｅ，ｒｏｉｅｒｌａｍｅ））：ＣＲＥＡＴＥＹＡＢＬＥａｄｍｉｎｉｌｓｅｒ（ｕＳｅｌ＂ｎｓ．ｍｅｖｓ．ｒｃｈａｒ（１６）ＮＯＴＮＵＬＬｄｅｆａｕｌｔｐａｓｓｗｏｒｄｔｉｎｙｂｌｏｂＮＯＴＮＵＬＬ，ＰＲＴＭＡＲＹＫＥＹ（ｕｓｅｒｒｉｏ．ｍｅ），ＵＮＩＯＵＥＫＥＹｕｓｅｒｒｌａｍｅ（ｕｓｅＦｌｌａ，ｌｎｅ））：ＣＲＥＡＴＥＤＡＴＡＢＡＳＥｒｂａｃ～ｕｒｉ：ｕＳｅｒｂａＣｕｒｉ：ＣＲＥＡＴＥＴＡＢＬＥＵＲＩＭｅｔａｄａｔａ（ｉｄＶＡＩｔＣＨＭｔ（６４）ＵＮＩＱＵＥＮＯＴＮＵＬＬｉｑ￡ｌｍｅＴＥＸＴ，ｄｅＳｃｒｉｐｔｉｏｎＴＥＸＴ．ｏｐ—ｒｉｇｈｔＴＥＸＴ，ＵｒｉＳｅｔＴＥＸＴ，ｕｓｅｒ—ｒｉｇｈｔＴＥＸＴ，ＰＲＩＭＡＲＹＫＥＹ（ｉｄ））：ＣＲＥＡＴＥＴＡＢＬＥＵｓｅｌ＂（ｉｄＶＡＲＣＨＡＲ（６４）ＵＮＩＱＵＥＮＯＴＮＵＥＬｒｌｉｊ，ｍｅＴＥＸＴ，ｄｅｓｃｒｉｐｔｉｏｎＴＥＸＴ，ｐａｓｓｗｄＴＥＸＴ，ＰＲＩＭＡＲＹＫＥＹ（ｉｄ））：ＣＲＥＡＴＥＴＡＢＬＥＵＳｅｌ－ｔａｂｌｅｎａｍｅｌｉＳｔ（ｕｌ＂ｉ—ｔａｂｌｅｎｉｌ，ｍｅＶＡＩ｛ＣＨＡＲ（６４）ＵＮＩＱＵＥ）：３４ＮＯＴＮ１ＪＬＬ基于角色的访问控制（ＲＢＡＣ）及应用研究ＣＲＥＡＴＥｕｒｉＴＡＢＬＥＵＲＩＬｉｓｔＳａｍｐｌｅ（ＶＡＲＣＨＡＲ（１２８）ＵＮＩＱｕＥＮＯ＇１１ＮＵＬＬ）：ＣＲＥＡＴＥＹ０１ｕｒｉｏｐｔｉｇｈｔＰＲＩＭＡＲＹｅＴＡＢＬＥａｃｌ一１ｉＳｔ（ＮＯＴＮＵＬＬ，ＶＡＲＣＨＡＲ（１２８）ＶＡＲＣＨＡＲ（１２８）ＶＡＲＣＨＡＲ（１２８）ＮＯＴＮＵＬＬ，ＮＵＬＬ，ＮＯＴＫＥＹ（ｒｏｌｅ，ｕｒｉ，ｏｐｒｉｇｈｔ））：ＣＲＥＡＴＥｕｓｅｒＴＡＢＬＥｕｓｅＦ—ｒｏｌｅ（ＮＯＴＮＵＬＬ。ＶＡＲＣＨＡＲ（Ｉ２８）ＶＡＲＣＨＡＲ（１２８）ＫＥＹ（ｕＳｅｒ，ｒｏｌｅ）ｙ０１ｅＮＯＴＮＵＬＬ，ＰＲＩＭＡＲＹ）：ｕＳｅｍｙｓｑｌ：ｕｓｅｒｕＰｄａｔｅｕＳＳｅｔｐａｓｓｗｏｒｄ＝ＰＡＳＳＷＯＲＤ（’７６１０２３’）ｗｈｅｒｅｅｒ２’ｒｏｏｔ’：ｆｌｕｓｈｐｒｉｖｉｌｅｇｅｓ：（２）数据库相关接口・用户名列表文件文件｝．１Ｓｔ保存用户名列表，数据格式设计如下：用户ｌ；用户２；用户３；用户４数据库中对应ｕｓｅｔｌｉｓｔ表，但表中只有一个字符串，如上面结构所示。ｉ１３ｔｒｅａｄＵＳｅｒＬｉｓｔＦｉｌｅ（ｃｈａｔ＊ｆｉｌｅｎａｍｅ）；调用数据存储动态库中的过程ｌｏａｄＵｓｅｒＦｒｏｍＤａｔａｂａＳｅｉｎｔｓｔｏｒｅＵｓｅｒＬｉｓｔＦｉｌｅ（ｃｈａｒ＇＊ｆｉｌｅｎａｂｌｅ）；调用数据存储动态庠中的过程ｓｔｏｒｅＵｓｅｒＴｏＤａｔａｂａｓｅ・角色定义文件文件格式文件｛．ｒｏｌｅ保存角色定义。数据格式设计如下：角色基数的文件格式：Ｒｏｌｅｓ＝｛Ｒ０１ｅｌ：ＣａｒｄｉｎａｌｉｔＹ，基于角色的访问控制（ＲＢＡＣ）及应用研究Ｒｏ］ｅ２：ＣａｒｄｉｎａｌｉｔＹＲｏｌｅｎ：Ｃａｒｄｉｎａｌｉｔｙ）数据库中对应ｒｏｌｅ—ｃａｒｄｉｎａｌｉｔＹ表，但ａｓｓｉｇｎｅｄ项目没填写。角色继承的文件格式Ｉｎｈｅｒｉｔｓ＝｛Ｐａｒｅｎｔｒ０１ｅ：Ｃｈｉｌｄｒｏｌｅ．Ｐａｒｅｎｔｊｒｏｌｅ：ＣｈｉｌｄＲ０１ｅ数据库中对应ｒ０１ｅ—ｉｎｈｅｒｉｔ表。角色动态互斥的文件格式Ｓｔａｔｉｃ—ｓｅｐａｒａｔｉｆｏｎ＝ｒ０１ｅ：ｓｅｐ—ＲｏｌｅｌＳｅｐ—Ｒｏｌｅ２．．．ｓｅｐ—Ｒ０１ｅｎ，ｒ０１ｅ：ｓｅｐ—Ｒ０１ｅ１Ｓｅｐ—Ｒ０１ｅ２．．．Ｓｅｐ—Ｒ０１ｅｎ）数据库中对应ｒｏｌｅ—ｓｅｐ表。三部分信息在同一个文件中，每个集合用｛｝隔开。接口字符串格式如下所示：Ｒｏｌｅ１：ＣａｒｄｉｌｌａｌｉｔＹ：Ｒ０１ｅ２：Ｃａｒｄｉｎａｌｉｔｙ：…Ｒ０１ｅｎ：ＣａｒｄｉｎａｌｉｔＹＰａｒｅｒｌｔＲ０ｌｅ：ＣｈｉｌｄＲ０１ｅ：ＣｈｉｌｄＲｏｌｅＲｏｌｅ：ＰａｒｅｎｔＲｏｉｅ：ＣｈｉｌｄＲｏｌｅ：…：Ｐａｒｅｎｔｒｏｌｅ：ｓｅｐ—Ｒｏｌｅｌｓｅｐ—Ｒ０１ｅＳｅｐ—Ｒｏｌｅｉ３ｅ２．．．Ｓｅｐ—Ｒ０１ｅｎ：…ｒ０１ｅ：ｓｅＰ—Ｒ０ｌｅ１２．．．Ｓｅｐ—Ｒ０１注１：字符串是连续的，不包含回车。注２：互斥关系字符串长度不定，“ｓｅｐ—Ｒｏｌｅ１ｓｅｐ—Ｒｏｌｅ２．一ｓｅｐ—Ｒｏｌｅ需要讨论，建议将ｎ：”作为一个字符串存放。ｉｎｔＳｔｏｒｅＲ０１ｅＤｅｆｉｎａｔｉｏｎＦｉｌｅ（ｃｈａｒ＊ｆｉｌｅｎａｍｅ）；调用数据存储动态库中的过程Ｓｔｏｒｅｒ０１ｅＩｎｆｏＴｏＤａｔａｂａｓｅ。ｉｎｔｒｅａｄＲｏｌｅＤｅｆｉｎａｔｉｏｎＦｉｌｅ（ｃｈａｒ＊ｆｉｌｅｎａｍｅ）；调用数据存储动态库中的过程１０ａｄＲ０１ｅＩｎｆｏＦｒｏｍＤａｔａｂａｓ。・角色图元信息文件文件格式基于角色的访问控制（ＲＢＡＣ）及应用研究４ｃｏ】ｏＦ＝１６５１２，１ｅｆｔ＝９９，ｔｏｐ＝１４，ｒｉｇｈｔ＝２３２，ｂＯｔｔｏｍ＝６４，ｔＹｐｅ＝４，Ｗｉｄｔｈ＝ｌ，ｃａｒｄｉｎａｔｙ＝５０００，ｄｅｓｉｇｎｅｄ＝０，ｒ０１ｅｒｌａｍｅ＝金融顾问４ｃｏｌｏｒ＝ｌ６５１２，１ｅｆｔ＝１７３，ｔＯｐ＝１８７，ｒｉｇｈｔ＝２７４，ｂＯｔｔＯｍ＝２３７，ｔｙｐｅ＝４，ｗｉｄＬｈ＝１，ｃａｒｄｉｎａｔＹ＝１００，ｄｅＳｉｇｎｅｄ＝０，ｒｏｌｅｒｔａｌｌｌｅ＝出纳６ｃｏｌｏｒ＝０，ｌｅｆｔ＝ｌ３９，ｔｏｐ＝５３５，ｒｉｇｈｔ＝４３３，ｂＯｔｔｏｍ：５５１，ｔＹＰｅ＝６，ｔｅｘｔ＝本角色图用于银行系统中，用于定义职能关系；６ｃＯｌｏｒ＝０，１ｅｆｔ＝１４０，ｔｏｐ＝５５３，ｒｉｇｈｔ＝４４８，ｂＯｔｔ０１７１＝５６９，ｔｙｐｅ２６，ｔｅｘｔ＝椭圆：代表角色，参数为｛角色名，基数，用户数）；６ｃＯｌｏｒ＝０，ｌｅｆｔ＝ｌ３９，ｔｏｐ＝５７３。ｒｉｇｈｔ＝４ｌ７，ｂｏｔｔｏｍ＝５８９，ｔＹＰｅ２６，ｔｅｘｔ：黑色箭头：代表继承关系，父角色一＞子角色；６ｃＯｌＯＦ＝０，ｌｅｆｔ＝１３９，ｔｏｐ＝５９２，ｒｉｇｈｔ＝５１７，ｂＯｔｔｏｒｎ＝６０８，ｔｙｐｅ＝６，ｔｅｘｔ２红色箭头：代表互斥关系，即用户不能同时同时拥有的角色：４ｃ０１０ｒ＝０，ｌｅｆｔ＝２０２，ｔ０１７＝４５０，ｒｉｇｈｔ＝３０３，ｂＯｔｔＯｍ＝５０２，ｔＹｐｅ＝４，ｗｉｄｔｈ＝１，ｃａｒｄｉｎａｔｙ＝－ｌ，ｄｅｓｉｇｎｅｄ＝０，ｒｏｌｅｒｌａｍｅ＝死人２Ｃｏｌｏｒ＝２５５，ｌｅｆｔ＝３００，ｔｏｐ＝４８０，ｒｉｇｈｔ＝４１９，ｂｏｔｔｏｍ＝４９３，ｔｙｐｅ２２，ｗｌｄｔｈ＝１，ｒｏｌｅＡ＝死人ＦＯｌｅＢ＝活人４ｃｏｌｏｒ＝０，１ｅｆｔ＝７０５，ｔｏｐ＝９７，ｒｉｇｈｔ＝８２８，ｂｏｔｔｏｍ＝１５３，ｔｙｐｅ＝４，ｗｉｄｔｈ＝ｌ，ｃａｒｄｉｎａｔｙ＝０，ｄｅｓｉｇｎｅｄ＝０，ｒｏｌｅｒｌＥｌｍｅ＝孤家数据库中对应ｒ０１ｅ—ｍａｐｉｎｆｏ表，每项对应文件中的～行。其中，角色定义的表达格式为：４ｃｏｌｏｒ，１ｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔｏｍ，ｔｙｐｅ＝４，ｗｉｄｔｈ＝１，Ｃｌｅｆｄｉｎａｔｙ，ａｓｉｇｎｅｄ．１－０１ｅｔｌａｎｌｅｓ继承关系定义的表达格式为：１Ｃ０１０ｒ，ｌｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂＯｔｔｏｍ，ｔｙｐｅ，ｗｉｄｔｈ，ｐａｒｅｎｔｃｈｉ】ｄ互斥关系定义的表达格式为：２ｃＯｌｏｒ，ｌｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔ０１１１，ｔＹｐｅ，ｗｉｄｔｈ，ｒ０１ｅＡｒｏｌｅＢ说明标签的表达格式为：６ＣＯｌＯｒ，１ｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔｏｍ，ｔＹｐｅ，ｔｅｘｔ；例如第一行代表一个角色的定义，图元代号为４，后面为颜色和坐标，最后三项为其“基数，已分配的用户数，角色名”。其它图元的格式可依此类推。接口字符串格式４ｃｏｌｏｒ，１ｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔｏｍ，ｔｙｐｅ＝４，ｗｉｄｔｈ２Ｉ，ｃａＦｄｉ３７ｎａｔＹ，ａｓｓ基于角色的访问控制（ＲＢＡＣ）及应用研究ｌｇｎｅｄ，ｒＯｌｅｎａｍｅ：１ｃ０１０ｒ，１ｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂＯｔｔｏｍ，ｔＹｐｅ．ｗｉｄｔｈ．Ｐａｒｅｎｔｃｈｉｌｄ２ＣＯｌｏｒ，ｌｅｆｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔｏｍ，ｔＹｐｅ，ｗｉｄｔｈ，ｒｏｌｅＡ６ＣＯｌｏｒ，１ｅ？ｔ，ｔｏｐ，ｒｉｇｈｔ，ｂｏｔｔｏｍ，ｔｙｐｅ，ｔｅｘｔ：ｒｏｌｅＢ注：字符串是连续的，不包含回车；●用户授权文件文件格式授权的格式为“用户名：角色ｌ，角色２，…，角色Ｎ”下面所示的文件内容就是一个用户授权信息文件。ＡｄｍｉｎｉｆｒｉＳｔｒａｔｏｒ：来访者ｅｎｄ：雇员，活人，来访者，内部顾问ＧｕｅＳｔ：出纳，雇员，活人ｈｕａｎｇＪｃ：部门经理数据库中对应ｕｓｅｒ—ａｕｔｈｏｒｉｔｙ表，每项对应文件中的一行。接口字符串格式如下：用户名：角色１，角色２，…，角色Ｎ；注：由于字符串的长度不能够确定，需要讨论，建议将“角色ｌ角色２，…，角色Ｎ；”作为一个整个的字符串。其中，元数据（抽象对象）的数据库表ＵＲＩＭｅｔａｄａｔａ中表示如下：ｉｄｎａｍｅ／／对象序列号，全局唯一。／／抽象对象名。ｄｅＳＣｒｉｐｔｉＯｎｏｐ～ｒｉｇｈｔｕｒｉＳｅｔ／／抽象对象文字描述／／对抽象对象的操作权限，用：／／资源集／／用户权限号隔开ＵＳｅｒ—ｒｉｇｈｔ（３）数据库表的结构：・用户表ＵＳＥＲ中结构内容：ｉｄｎａＩｎｅ用户ＩＤ名称ｄｅｓｐａｓｏｒｉｐｔｉｏｎ描述ｓｗｄ口令・每个抽象对象的资源集用一个数据库ｕＲＩＬｉｓｔＳａｍｐｌｅ表示为ｕｒｉ资源名ａｂ基于角色的访问控制（ＲＢＡＣ）及应用研究一．ＬＳ皓锄ｐｌｅ都有一个表名，所有表名存在所鲫ａ有雌的ＨＳＣ时表Ｕ中ｕｒｉｔａｂｌｅＤａｍｅｕｒｉ表名・访问控制列表ａｃｌ－ｌｉＳｔ的内容：ｒ０１ｅ角色名ｕｒｉｕｒｉｏｐｒｉｇｈｔ操作权限。创建数据的步骤・启动ｍｙｓｑｌ的服务・进入ｍｙｓｑｌ的ｂｉｎ目录，执行：ｍｙｓｑｌ—ｕｒｏｏｔ—Ｐ１２３・执行：ｃｒｅａｔｅｄａｔａｂａｓｅｒｂａｃａｄｍｉｎ：・执行：ｅｘｉｔ，退出ｍｙｓｑｌ管理控制界面・执行：ｍｙｓｑｌｒｂａｃａｄｍｉｎ＜ｒｂａｃａｄｍｉｌｑ．ｓｑｌ・配置０ＤＢＣ数据原（４）数据库相关调用示例・执行一致性检查调用ｉ１３ｔ（￥ｌｄａｐＳｔｏｒｅＰｒｏｃ）（）：ＨＩＮＳＴＡＮＣＥｈｎｌｏｄ：：时＂ｙ训ｍ∞：扣儿州∞儿儿Ｄ№＂●ＭｅＳＳａｇｅＢⅣＯＸ（错误动态连接库调用失败！”）ｒｅｔＵｒｎ．．ｌｄａｐＳｔｏｒｅＰｒｏｃ２（ｈｍｏｄ，”ｃｈｅｃｋＣｏｎｓｉｓｔｅｎｃｙ”）ｉｆ（１ｄａｐＳｔｏｒｅＰｒｏｃ＝＝ＮＵＬＬ）ＭｅＳｓａｇｅＢｏｘ（”错误：不能定位动态连接库的函数入口！”）ＦｒｅｅＬｉｂｒａｒｙ（ｈｍｏｄ）：ｒｅｔｕｒｎ：３９基于角色的访问控制（ＲＢＡＣ）及应用研究ｉｎｔｒｅｔ＝（｛１ｄａｐＳｔｏｒｅＰｒＯＣ）（）：ＦｒｅｅＬｉｂｒａｒＹ（ｈｍｏｄ）：ｉｆ（ｒｅｔ＝＝一１）ＭｅｓｓａｇｅＢｏｘ（”数据库操作失败”）：ｉｆ（ｒｅｔ＝＝Ｏ）ＭｅｓｓａｇｅＢｏｘ（”成功，没有执行一致性更改”）ｉｎｔｒｅｔｎ：ｉｆ（ｒｅｔ＝＝１）／／读取用户名列表文件ＵｐｄａｔｅＤａｔａ（ＴＲＵＥ）：ｉｆ（ｍ—ｕｓｅｒｌｉｓｔ—ｃｈｅｃｋ＝＝ＴＲＵＥ）｛Ｃｈａｒ￥ｕｓｅｒＬｉＳｔＦｉｌｅＮａｍｅ：ⅧＵｓｅｒＬｉｓｔＥｄｉｔ．ＧｅｔＢｕｆｆｅｒ（ｍ—ＵｓｅｒＬｉｓｔ—Ｅｄｉｔ．ＧｅｔＬｅｎｇｔｈ０）ｒｅｔｎ＝ｒｅａｄＵｓｅｒＬｉｓｔＦｉｌｅ（ｕｓｅｒＬｉｓｔＦｉｌｅＮａｍｅ）：ｉｆ（ｒｅｔｎ＝＝０）ＯｕｔＭｅｓｓａｇｅ（”用户列表信息文件文件下载成功！”）：／／可改为ＭｅＳｓａｇｅＢｏｘｅｌｓｅｉｆ（ｒｅｔｎ＝＝１）ＯｕｔＭｅｓｓａｇｅ（”错误：动态连接库调用失败！”）：ｅ１ｓｅｉｆ（ｒｅｔｎ＝＝２）ＯｕｔＭｅｓｅｌＳｅｓａｇｅ（”错误：用户名列表文件不能打开！”）：ｉｆ（ｒｅｔｎ＝＝３）ＯｕｔＭｅｓｓａｇｅ（”错误：不能定位动态连接库的函数入口！”）ｅｌｓｅｉｆ（ｒｅｔｎ一１）ＯｕｔＭｅｓｓａｇｅ（”用户列表信息文件下载失败！”）：ｅ１ｓｅＯｕｔｉｅｓｉｆ（ｒｅｔｎ一２）ｓａｇｅ（”警告：未进行任何操作！“）：／／读取用户授权信息文件ｉＩｆ（ｍ—ｕｓｅｒａｕｔｈ—ｃｈｅｃｋ＝＝ＴＲＵＥ）墨±．鱼．鱼．堕塑丝型！垦呈垒兰！堡窒旦婴壅Ｃｈａｒ｝ｕＳｅｒＡｕｔｈＦｉｌｅＮａｍｅ２ｍ—ＵＳｅｒＲｏｌｅＡＳＳｉｇｎｅｄＥｄｉｔ．ＧｅｔＢｕｆｆｅｒ（ｍ＿ＵｓｅｒＲｏｌｅＡＳＳｉｇｎｅｄ—Ｅｄｉｔ．ＧｅｔＬｅｎｇｔｈ（））：ｒｅｔｎ＝ｒｅａｄＵＳｅｒＡｕｔｈＯｒｉｔＹＦｉｌｅ（ｕＳｅｒＡｕｔｈＦｉｌｅＮａｍｅ）ｉｆ（ｒｅｔｎ＝＝０）ＯｕｔＭｅＳｓａｇｅ（”角色授权文件文件下载成功！”）ｅ１ｓｅｉｆ（ｒｅｔｎＯｕｔＭｅｓｓａｇｅ（”错误：动态连接库调用失败！”）ｅｌｓｅｉｆ（ｒｅｔｎＯｕｔＭｅｓｓａｇｅ（”错误：角色授权文件不能打开！”）ｅ１ｓｅｉｆ（ｒｅｔｎＯｕｔＭｅｓｓａｇｅ（”错误：不能定位动态连接库的函数入口！”）ｅ１ｓｅｉｆ（ｒｅｔｎ—１）ＯｕｔＭｅＳｓａｇｅ（”角色授权信息文件下载失败！”）：ｅ１ｓｅｉｆ（ｒｅｔｎ一２）ＯｕｔＭｅｓｓａｇｅ（”警告：未进行任何操作！”）：｝ＵｐｄａｔｅＤａｔａ（ＦＡＬＳＥ）：ＭｅｓｓａｇｅＢｏｘ（”成功，执行了一致性更改“）用户名列表文件ｎｔｒｅａｄＵＳｅｒＬｉＳｔＦｉｌｅ（ｃｈａｒ￥ｆｉｌｅｎａｍｅ）ＦＩＬＥ｝ｕｌｐｔｒ：１１２ｔ（｝１ｄａｐＳｔｏｒｅＰｒｏｅ）（ｃｈａｒ＊）ＣｈａｒｔｍｐＳｔｒｉｎｇ［２００００］：Ｃｎａｒｓｅｐｓ［】＝”：＼ｎ”ｃｎａｒ￥ｔＯｋｅｉｌ：ｉｎｔｒｅｔｉ＂１：ＨＩＮＳＴＡＮＣＥｈｍｏｄｈｍｏｄ＝：：ＬｏａｄＬｉｂｒａｒｙ（”ｄａｔａＢａｓｅＳｔｏｒｅ．ｄ１１”）ｉｆ（ｈｍｏｄ＝＝ＮＵＬＬ）４１・下载ｌ——————————苎！羔哩缈塑．蕉型！垦堡垒旦！丝窒旦塑壅．｛ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：动态连接库调用失败！“，”警”，ＮＵＬＬ）：ｒｅｔｕｒｎ告１：｝ｕｌｐｔｒ２ｆｏｐｅｎ（ｆｉｌｅ１２ａｍｅ，”ｗ”）ｉｆ（！ｕｌｐｔｒ）ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：用户名列表文件不能打开！“，”警”，ＮＵＬＬ）：ｒｅｔｕｒｎ告２：１ｄａｐＳｔｏｒｅＰｒｏｃ＝（ｉ１２ｔ（｝）（ｃｈａｒ＊））ＧｅｔＰｒｏｃＡｄｄｒｅｓｓ（ｈｍｏｄ，”１０ａｄＵｓｅｒＦｒｏｍＤａｔａｂａｓｅ”）：ｉｆ（１ｄａｐＳｔｏｒｅＰｒｏｃ＝＝ＮＵＬＬ）｛ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：不能定位动态连接库的函数入口！””警ＦｒｅｅＬｉ告”，ＮＵＬＬ）：ｂｒａｒｙ（ｈｍｏｄ）；ｆｃｌｏｓｅ（ｕｌｐｔｒ）：ｒｅｔｕｒｎ３：）ｒｅｔｌ２２（￥ｌｄａｐＳｔｏｒｅＰｒｏｃ）（ｔｍｐＳｔｒｉｎｇ）ｔｏｋｅｎ＝ｓｔｒｔｏｋ（ｔｍｐＳｔｒｉｎｇ，ｓｅｐｓ）：ｗｈｉｌｅ（ｔｏｋｅｎｆ＝ＮＵＬＬ）ｆｆ鼻Ｗｒｉｔｅｉｔｔ０ｔｈｅｆｉｌｅ年｝ｆｐｒｉｎｔｆ（ｕｌｐｔｒ。”％Ｓ＼ｎ９，ｔｏｋｅｎ）／｛Ｇｅｔｒｌｅｘｔｔｏｋｅｌ２：￥／ｔｏｋｅｎ＝ｓｔｒｔｏｋ（ＮＵＬＬ，ｓｅｐｓ）：４２基于角色的访问控制（ＲＢＡＣ）及应用研究ｆｃｌｏｓｅ（ｔｌｌＰｔｒ）：ＦｒｅｅＬｉｂｒａｒＹ（ｈｍｏｄ）ｒｅｔｕｒｎｒｅｔｎ：）・下载用户授权文件ｉｎｔ｛ＬｒｅａｄＵｓｅｒＡｕｔｈｏｒｉｔｙＦｉｌｅ（ｃｈａｒ＊ｆｉｌｅｎａｍｅ）ＦＩＬＥ＊ｉｎｔｕａｐｔｒ：（｝１ｄａｐＳｔｏｒｅＰｒｏｃ）（ｃｈａｒ＊）：ｃｈａｒｔｍｐＳｔｒｉｎｇ［４００００］：Ｓｅｐｓ［］￥ｔｏｋｅｎ：ｒｅｔｎ：ｃｈａｒｃｈａｒｉｎｔ＝”：＼ｎ”：ＨＩＮＳＴＡＮＣＥｈｍｏｄ：ｈｍｏｄ＝：：ＬｏａｄＬｉｂｒａｒｙ（”ｄａｔａＢａｓｅＳｔｏｒｅ．ｄｌｌ”）：ｉｆ（ｈｍｏｄ＝＝ＮＵＬＬ）｛ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：动态连接库调用失败！”，”警”，ＮＵＬＬ）：ｒｅｔｕｒｎ告１：）ｕａｐｔｒ＝ｆｏｐｅｎ（ｆｉｌｅｎａｍｅ，”ｗ”）：ｉｆ（！ｕａｐｔｒ）｛ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：用户名列表文件不能打开！”，”警告”，ＮＵＬＬ）：ｒｅｔｕｒｌ］２：）１ｄａＤＳｔｏｒｅＰｒｏｃ（ｉｎｔ（｛）（ｃｈａｒ＊））ＧｅｔＰｒ０ＣＡｄｄｒｅｓｓ基于角色的访问控制（ＲＢＡＣ）及应用研究（ｈｍｏｄ，”ｌｏａｄＵｓｅｒＡｕｔｈｏｒｉｔｙＦｒｏｍＤａｔａｂａｓｅ”）：ｉｆ（１ｄａｐＳｔｏｒｅＰｒｏｃ＝＝ＮＵＬＬ）｛ＭｅｓｓａｇｅＢｏｘ（ＮＵＬＬ，”错误：不能定位动态连接库的函数入口告”，ＮＵＬＬ）：ｂｒａｔｙ（ｈｍｏｄ）：”警ＦｒｅｅＬｉｆｃｌ０Ｓｅ（ｕａｐｔｒ）：ｒｅｔｕｒｎ３：｝ｒｅｔｎ＝（｝１ｄａｐＳｔｏｒｅＰｒｏｃ）（ｔｍｐＳｔｒｉｎｇ）ｔｏｋｅｎ＝ｓｔｒｔｏｋ（ｔｍｐＳｔｒｉｎｇ，ｓｅｐｓ）ｗｈｉｌｅ（ｔｏｋｅｎ！＝ＮＵＬＬ）｛／％Ｗｒｉｔｅｆｐｒｉｉｔｔｏｔｈｅｆｉｌｅ｝／ｎｔｆ（ｕａｐｔｒ，”％ｓ＼ｎ”，ｔｏｋｅｎ）ｎｅｘｔｆ≈Ｇｅｔｔｏｋｅｎ：卑｜ｔｏｋｅｎ＝ｓｔｒｔｏｋ（ＮＵＬＬ，ｓｅｐｓ）：｝ｆｃｌ０Ｓｅ（Ｕａｐｔｒ）：ＦｒｅｅＬｉｂｒａｒＹ（ｈｍｏｄ）３．７．３资源收集模块概要设计通过对资源标识方法的分析，该模块可以实现对常用资源，如ｗｅｂ资源的表示和收集工作，同时以界面友好的方式提供对资源的访问授权，最后形成查找效率高的存储权限文件供Ａｃｄｆ调用：该模块的功能设计基于以下两项需求：（１）ＲＢＡＣ可以对多种资源进行授权和访问控制；基于角色的访问控制（ＲＢＡＣ）及应用研究（２）权限控制文件与目标对象的存储分离；权限控制文件与目标对象的存储分离的定义：认为在ｔｉＢＡＣ应用中，对象为受保护的资源，对对象的标识，实际是是对受保护的资源的标识，该需求实际上是为了确定一个合适的资源标识框架。权限控制文件与对象分离的含义及其所带来的问题：所谓权限控制文件与对象分离，是指权限控制文件的存贮在”物理”位置上与资源的存储独立，所引发的问题包括：资源的收集：如何获得受控资源的清单，是用户提供，还是程序自动完成？收集到的资源清单如何展现？是根据资源存贮的”物理”结构，还是根据资源本身的语义结构？收集到的资源清单如何存贮？是根据资源存贮的”物理”结构，还是根据资源本身的语义结构？存贮结构与资源查找／定位（Ａｃｄｆ的需求）的效率有密切的关系。在资源位置。内容发生变更的情况小，如何保证其与资源标识的一致性。针对以上分析，将需求分解为四个子模块：资源的采集，选择，授权，存储模块，并形成如下系统总体结构。３７．３．１模块功能（１）资源的采集该模块的主要功能是提供工具（算法），以及必要的用户界面以帮助所控资源的收集，并将资源集转换为标识集，用一定格式保存以供资源选择模块使用。（２）资源选择用户在以某种语义结构所展现的资源清单中选择相应资源标识，不同的资源内在的语义结构不一，如对于树状结构的ｕＲＩ资源，模块通过分析资源集的结构，形成ＵＲＩ树提供用户进行浏览和权限赋予操作。（３）资源授权根据角色对资源进行授权，在ＧＵＩ（Ｇｒａｐｈ权。ｕｓｅｒＩｎｔｅｒｆａｃｅ）中进行。模块提供资源列表和角色列表，用户根据上述列表对资源的访问进行授（４）资源权限文件存储模块将用户所完成的资源授权信息存储在磁盘，要求存储格式适合ｈｃｄｆ基于角色的访问控制（ＲＢＡＣ）及应用研究的快速匹配和查找。３．７．３．２总体设计系统总体结构如图３—１４锄—誓图３．１４资源收集模块图（１）子模块说明・资源的采集功能说明：为了实现资源标识与资源位置的分开，必须引入资源采集模块，该模块的主要功能是提供工具（算法），以及必要的用户界面以帮助所控资源的收集，并将资源集转换为标识集，用一定格式保存以供资源选择模块使用。模块的设计考虑包括如下问题：目标对象的表示：为适应资源本身的多样性，以及考虑到可扩展性，采用统一资源标识（ＵＲＩ）进行资源标识／定位。操作流程：生成从资源集到ＵＲＩ集的映射由于所面对的资源类型多样（这也是采用ＵＲＩ进行资源标识的原因），无法形成一个统一的资源收集算法。所以，应针对不同的资源开发不同的资源收集模块。例如，针对ＵＲＬ（Ｕｎｉｆｉｅｄ—１ＲｅｓｏｕｒｃｅＬｉＳｔ）资源的收集，采用如图３５的流程：基于角色的访问控制（ＲＢＡＣ）及应用研究用户指定ｗｗｗｒｏｏｔ例如：ｗｗｗ，ｗｅｓｔｏｎｅ．ｃｏｍ旦用户指定虚拟目录例如：ｃ：＼＼ｗｗｗｒｏｏｔ＼ｗｅｓｔｏｎｅ＼＼ｄｏｃｃ尊～向ｌ｜ｍｗｗｒｎｎｌｌ。配…［ｗｅ…＝ｔｏｎｅＩ白［鱼［ｄｅｃ］以目录的方式选辑咱［ｐｒｏｊｅｃｔ］虚拟目录下文件图３－１５资源收集结构的存贮功能说明：将资源采集所得到的结果集保存为一维表结构的资源清单。操作流程：用户在获得资源集清单后，点击“保存”按钮，系统弹出文件保存对话筐，用户在指定文件名后，系统将所收集到的资源标识集以一维表的形式保存在磁盘。说明：不同资源的层次／逻辑结构不同，资源收集算法的输出结果以“一维表”的方式暂存。图３—１６为网页一维表。图３—１６网页一维表对于ｅｍａｉｌ资源，如邮件地址的一维表见图３—１７。基于角色的访问控制（ＲＢＡＣ）及应用研究・资源选择功能说明：用户在以某种语义结构所展现的资源清单中选择相应资源标识。操作流程：用户通过鼠标点击，正则表达式匹配等方式（根据资源类型的不同）选择资源集，系统将已经选定的资源以一维列表方式展现。说明：对不同的ＵＲＩ资源集，应采用不同的权限赋予界面。例如，对于某些有层次语义的资源，如ＵＲＬ，在进行授权操作时可能需要类似“将权限扩展到子节点”的操作，而对于没有层次语义，但具有群组语义的资源，如Ｅｍａｉｌ，可能希望进行群组操作。～个典型的ｕＲＬ集合，可以形成一个单根树，见图３—１８。图３—１８ＵＲＬ树・资源授权功能说明：根据角色对资源进行授权操作说明：用户选定一个资源，某个角色，并选定访问方式，点击”赋予”按钮，系统将该资源的相应访问权限赋予角色。说明：参照ＲＢＡＣ的授权模式，如图３—１９所示：图３—１９授权模式・资源存储功能说明：将用户所完成的资源÷授权信息存储在磁盘。操作说明：用户点击保存，系统将用户所完成的资源《－授权信息存４８基于角色的访问控制（ＲＢＡＣ）及应用研究储在磁盘。说明：基本的，对于一维表方式存储的资源，可以用线性方式进行查找，但效率较低。对于某些类型的资源，可以根据资源的语义进行逻辑分组，每组ＵＲＩ仍然以一维表的方式存储。对于层次结构的资源，可以应用某些优化算法进行存储。（２）一个针对ｕＲＬ的用例综合以上的功能叙述，针对ＵＲＬ资源存贮，有用例如下图３—２０Ｃ：—＼—＼—ｗ—ｗｗｒｏｏｔ＼＼ｗｅｓｔｏｎｅ＼＼ｄｏｃ＼＼—ｒ—ｅ——ｐ——ｏｒｔ＼＼ｒ—２—．ｈｔｍｌＪｈｔｔｐ：／／ｗｗｗ．ｗｅｓｔｏｎｅ．ｃｏｍ／ｒｅｐｏｒｔ／ｒ２．ｈｔｍｌ』上授权模块ｌｌ，』、，多，＼为…’＼一／■—、椅’，７臂珙ｌ茎据ｉｗｗｗ＿ｗｅｓｔｏｎｅ＿ｃｏｍ＿ｒｅｐｏｒｔ＿ｒ２．∞ｌｌ一／／一＿＾（＝｜）ｒＩ。、＞出＝一：图３—２０ＵＲＬ的用例万＿浏览器请求＿对ＵＲＬ资源选择系统原型的说明：根据图中流程，用户操作与系统交互分为如下步骤：第一步：资源收集●用户指定某个ＵＲＬ域（如ＨＴＴＰ标识）。●指定该域的文档根目录，系统将该目录的结构以树状结构展现。●用户从中选取相应需要受保护文件。●系统根据用户选择形成ＵＲＬ，并加入到列表中。第二步：资源授权步骤如下：４９～基于角色的访问控制（ＲＢＡＣ）及应用研究●用户选定一个资源。・选定某个角色。●选定访问方式。・点击”赋予”按钮。・系统将该资源的相应访问权限赋予角色。第三步：资源存储用户点击保存，系统将用户所完成的资源÷授权信息存储在磁盘。（３）相关模块设计根据以上讨论，本需求仅针对Ｗｅｂ资源（ｕＲＬ）标识进行，由于ｕＲＬ是ｕＲＩ的子集，可以通过扩展实现对ＵＲＩ标识资源的操作。ＵＲＬ资源收集显示／子模块●拼装ＵＲＬ列表ｖＯｉｄＳｅｔｗｗｗＲｏＯｔ（ＳｔｒｉｎｇｒＯＯｔ）：为了拼装一个合法的ＵＲＬ，用户首先需要指定需要保护ＵＲＬ的虚拟根，例如：ｈｔｔＰ：／／ｗｗｗ．ｗｅｓｔｏｒ］ｅ．ｔｏｍ／ＳｅｃｒｅｔＶＯｉｄ０ｐｅｎＤｉｒＢｒｏｗｓｅｒ（）激活文件选择系统文件选择对话框，以供用户选择所需要保护【ＪＲＬ的本地磁盘目录。ｓｔｒｉｎｇ［］ＧｅｔＦｉｌｅＬｉＳｔ（ｓｔｒｉｎｇｄｉｒ）递归的获得指定目录下的所有文件列表，在返回字符串数组中，同时包含子目录和文件名信息。Ｓｔｒｉｎｇ［］ＡｓｓｉｇｎＵＲＬ（Ｓｔｒｉｎｇｗｗｗｒｏｏｔ，Ｓｔｒｉｎｇ［］ｆｉｌｅｌｉＳｔ）从ＵＲＬ虚拟根和文件列表中拼装为ＵＲＬ列表，拼装后的列表为一维字符数组，如图３—２１所示：图３—２ｌＵＲＬ列表Ｓｔｒｉｎｇ［］ＣｈｅａｋＵＲＬ（Ｓｔｒｉｎｇ判断拼装出ＵＲＬ是否合法。ｕｒｌｌｉＳｔ［］）由于由上述步骤得到的ＵＲＬ列表从磁盘目录中得到，没有语义信息，所以需要进行合法检查。如果全部合法，返回字符数组为空，如果有“非法”ＵＲＬ，保存在ｓｔＦｉｎｇ［］数组中。基于角色的访问控制（ＲＢＡＣ）及应用研究Ｓｔｒｉｎｇ［］ＤｅｌｅｔｅＥｒｒｏｒＵＲＬＬｉｓｔ（Ｓｔｒｉｎｇｕｒｌｌｉｓｔ［］）ＴｏＢｅＤｅ】ｅｔｅ［］，Ｓｔｒｉｎｇ从ＵＲＬ列表中删除“非法”的ＵＲＬ，返回ＵＲＬ结果字符串数组。ｖｏｉｄＰａｒｓｅＵＲＬＡｓＴｒｅｅ（ｓｔｉｒｎｇ［］ＬｉｔｌｌｉＳｔ）将一维结构的ＵＲＬ列表表现为树状结构，如图３—１８所示。说明，为了方便进行树遍历，将树设计为单根形式，即认为ＵＲＬ为所有节点的根节点。ｉｎｔＬｉｓｔＵＲＬ（ＣＴｒｅｅＶｉｅｗ％ｔｖＴｒｅｅＶｉｅｗ，ＨＴＲＥＥＩＴＥＭｔｉＩｔｅｍ）在用户点击某个节点时，递归的搜寻该节点下的所有子节点，并存ＧＵＩ的列表框中显示，用于将授权信息扩展到子目录及文件中。ＭａｐＡｓＳＳｉｎｇＡｕｔｈ（ＳｔｒｉｒｎｇＲ０１ｅ，ＳｔｒｉｎｇＵＲＬ，ＳｔｒｉｎｇＯｐ）将ＵＲＬ资源的访问权限Ｏｐ赋予角色Ｒｏｌｅ，并保存在对应该ＵＲＬ的角色一访问权限映射中。・保存模块ＶｏｉｄＳｅｔＤｉｓｋＳａｖｅＰａｔｈ（）用户指定保存在本地磁盘的路径。ＶｏｉｄＳａｖｅＡｓｓｉｇｎｅｄＡｕｔｈＴｏＤｉＳｔｒｉｌｌｇｓｋ（Ｓｔｒｉｎｇ［］Ｒ０１ｅｌｉｓｔ，ＳｔｒｉｎｇＵＲＩ．，Ｐａｔｈ）对上节描述的操作进行保存，Ｐａｔｈ为本地磁盘的路径。，说明：为了提高Ａｃｄｆ的查找效率，将某个ＵＲＬ映射为一个权限控制文件，如图３—２２所示。图３—２２ＵＲＬ映射为权限控制文件其中，％ＡｕｔｈＰａｔｈ％为用户指定的保存路径，并将ＵＲＬ头ｈｔｔｐ：／／去掉，余下字符中，将“。”ｈｔｍｌ”去掉。和“／”都替换为“一”，最后将后缀“。Ａｃｄｆ在定位某个ＵＲＬ相应的授权文件中，首先定位％ＡｕｔｈＰａｔｈ％，在执行（１）的逆操作。——————————ｌ邑至鱼皇塑堕囹垫型！垦堡垒竺！墨窒旦竺壅・数据库更新接口实现设计说明该ＤＬＬ只有一个函数，函数体如下：ｓｐｅｃ（ｄｌｌｅｘｐｏｒｔ）一ｄｅｃｌＵ１］ｄａｔｅＤＢＡＰＩ（ＵＳＥＲＩＮＦＯＬＩＳＴ＊ｐｕｓｅｔｌｉｓｔ）ｅｘｔｅｌＴｎ”Ｃ“１３００Ｌ／／ｈｅｒｅＰｌａｃｅａｔｅｓｔｄａｔａＵＳＥＲＩＮＦＯＬＩＳＴ－ｉｆ（ｐｕｓｅｌ＂１ｉｓ＿１ｃ＝＝ＮＵＬＬ）ｐｕｓｅｔｌｉｓｔ＝ｎｅｗ／水／／ａｄａｔａＵＳＥＲＩＮＦＯｉｎｐｕｔ８ｔｅｓｔｐＵｓｅｒＩｎｆｏ＝ｎｅｗ［ＪＳＥＲＩＮＦＯ：ｓｔｒｃｐｙ（ｐＵｓｅｒＩｎｆｏ一＞ｓｚＵｓｅＦｎＥｔｍｅ，”ａｂｃ”）：／／ｐｕｓｅｌ－Ｉｎｆｏ一＞ｓｚｌＪｓｅｒｌ３．１３，ｍｅ＝”ａｂｃ”－ｐＵｓｅｒＩｎｆｏ一＞Ｏｐｅｒａｔｉｏｒｌ＝（ｅ１３ＵｌｌｌＳＴ—ＵＳＥＲＩＮＦＯ：：ＯＦ＇）ＯＰ—ＤＥＬＥＴＥ；／／ｏＰ—ＩＮＳＥＲＴｐｕｓｅｒｌｉｄｅｌｅｔｅｒｅｔｕＴｒｌＳｔ一＞ｉｎｓｅｒｔ（ｐｕｓｅｒｌｉｓｔ一＞ｅｎｄ０，＊ｐＵｓｅｒＩｎｆｏ）：ｐＵＳｅｒＩｎｆｏ：￥／ｔｒｕｅ：）功能是填写一个ＵＳＥＲＩＮＦＯ的链表，链表采用的是标准ＳＴＬ库的ｌｉｓｔ，用迭代子进行操作，函数体中的注释部分有可参考代码。ｔｙｐｅｄｅｆｓｔｒｕｃｔｆＣｈａｒｃｈａｔｅｒｌｕｍｓｚＵｓｅｒｒｌａｎｌｅ［１２８］：ｓｚＵＩＤ［１２８］：ＯＰ｛ＯＰ—ＩＮＳＥＩ｛Ｔ＝Ｏ，ＯＰ—ＤＥＬＥＴＥ＝１｝Ｏｐｅｒａｔｉｏｎ：ｊＳＴＵＳＥＲＩＮＦＯ：ｔＹＰｅｄｅｆＳＴ—ＵＳＥＲＩＮＦＯＵＳＥＲＩＮＦＯｔｙｐｅｄｅｆｔｙｐｅｄｅｆｌｉＳ“ＳＴ～ＵＳＥＩ｛ＩＮＦＯ＞ＵＳＥＲＩＮＦＯＬＩＳＴ：：ｉｔｅｒａｔ０１＂ＵＳＥＲＩＮＦＯＩＴＥＩ｛ＡＴＯＲｌｉｓｔ＜ＳＴ～ＵＳＥＲＩＮＦＯ＞３．８本章小结本章对ＲＢＡＣ系统的具体设计和实现进行了阐述，包括Ｉ｛１３ＡＣ的６个５２基于角色的访问控制（ＲＢＡＣ）及应用研究功能模块，一个集成工具，一个ＲＢＡＣ的二次开发包一访问控制接口模块，以及ＲＢＡＣ设计和实现中使用到的关键技术。用户通过这些技术和工具就可以将ＲＢＡＣ用到实际的应用中。基于角色的访问控制（ＲＢＡＣ）及应用研究第四章ＲＢＡＣ典型应用４．１应用中集中权限管理的优势在应用中，针对权限的管理分散带来的问题，我们提出了集中的权限管理策略，这种策略就是以基于角色的权限管理模型为基础而开发的。通过某种方式比如ＬＤＡＰ来管理用户的权限，并称其为数据中心，而数据中心是建立在基于角色的权限管理模型基础之上的。实现权限集中管理是为了解决应用中所遇到的权限分散管珲所带来的问题，而权限集中管理的好处表现在以下几点：（１）提高了企业的效率集中了所有应用系统的权限管理功能，提高了系统管理的效率。（２）统一了权限管理模型对所有的应用都实现了基于角色的权限管理模型，使得对整个企业数据的管理变得更加有序合理。（３）方便管理对本企业的所有数据都采用了一致的权限分配方式，从本质上改变了企业内部数据管理混乱的状况。（４）减轻了系统管理员的负担对所有应用的权限都集中统一管理，使得系统管理员可以通过一个统一的管理界面来管理所有应用系统的权限，这大大减轻了系统管理员的负担。（５）增强了系统的安全性因为所有应用都通过统一的权限管理系统来管理，这样就可以方便地对系统的安全模块进行升级或改造，从而增强系统的安全性。（６）降低了新应用系统的开发成本，提高了开发效率因为我们对新的应用系统提供统一的权限管理模式和ＡＰＩ，凶此当开发商开发新的应用系统时，就不必再考虑权限管理的问题，而直接将模块集成到新系统中就可以了。这就大大降低了系统的开发成本，提高了系统的开发效率。（７）权限继承性这是基于角色权限管理的一个重要特点，在权限分配时，基于角色基于角色的访问控制（ＲＢＡＣ）及应用研究的权限继承分配。权限集中管理系统之所以采用基于角色的管理模型也是因为传统的权限管理方式管理代价太大，而基于角色的权限管理模型管理的复杂度相对降低。在充分理解了基于角色的权限管理模型的基础上，我们提出了数据中心模型，通过此数据中心实现对权限的控制和管理。４．２访问控制使用的三种集中管理方式实际应用中的访问控制模型可以根据用户的不同要求进行定制。主要可分为如下三种：（１）以数据资源为中心的数据中心管理方式；（２）以用户资源为中心的数据中心管理方式；（３）前两种方式的综合，也称为分级管理方式。这三种不同的数据中心管理方式是根据应用的不同情况和用户的要求来决定的，下面分别加以介绍。４．２．１以数据资源为中心的数据中心管理方式这主要是为了支持完全基于Ｗｅｂ的应用系统。这种方式的数据中，己组织结构如图４—１所示：图４—１数据资源为中心的结构如果采用的是这种方式，则虚拟数据资源存放的是实际上Ｗｅｂ资源的虚拟文件名和目录。这种方式的优点在于：所有的权限验证都是在应用系统之外进行的，不需要在应用系统的内部做任何权限处理的工作。对于一些老的应用系统来说，如果此应用系统是完全基于Ｗｅｂ的应用，或者原有的系统没有权限控制，需要增加权限控制，并且只要求将权限控制到文件一级，那么这种方式是最佳选择。因为不需要对原有的应用系统做任何改动，而只需要在系统之外增加此权限的集中控制，就可以达到权限集中控制基于角色的访问控制（ＲＢＡＣｊ及应用研究的目的。但是，这种方式也存在一个较大的缺点：权限控制粒度较粗，只能控制到文件一级。因此，如果原有的系统是建立在数据库基础之上的，并且要求对权限的控制达到文件内容或数据字段一级，此方式就达不到要求。另外，在这种方式下，用户的角色对所有的应用系统而言是固定的。也就是说，一旦用户的角色被分配以后，除非重新分配，否则此用户的角色就是固定不变的。如果采用这种方式进行权限控制，则整个系统的体系结构如下图所不：管理用户图４—２以数据资源为中心的管理方式４．２．２以用户资源为中心的数据中心管理方式这种方式主要是为了适应那些要求细粒度权限控制的需求而定制的。在数据中心中只对用户进行角色的分配，而权限的控制和验证是在应用系统内部完成的。中心结构如图４－３所示：广刨］—画Ｌ固Ｊ一图４－－３以用户资源为中心的数据中心５６除了在数据中心中可以固定地对用户分配角色外，在应用系统内部还可以根据系统的流程来确定当前用户的角色。这种方式的优点有两个：能进行细粒度权限控制：能动态确定用户的角色。基于角色的访问控制（ＲＢＡＣ）及应用研究如果应用系统原来是通过访问控制列表来实现权限控制的，可以通过对应用系统的修改来实现基于角色的集中统一管理，这样就能保证细粒度的权限控制。但这种方式有一个最大的缺点：需要在应用系统内部实现对权限的验证。如果系统是老的应用系统，则需要对原来的应用系统的结构或源代码进行修改。如果是新系统，则需要新系统通过权限集中管理系统提供的接口来实现权限的验证，并且需要按数据中心中的角色划分方法进行权限控制的验证。从上面的分析可以看出，这两种方式有着各自的优缺点，选择什么样的方式是由用户根据需求和应用的具体情况来决定的。如果选择这种方式，首先需要判断用户的身份，如果身份验证成功就给用户分配相应的角色，根据此角色可以访问某些数据。而且在访问的过程中，可以根据当前条件的不同更改用户的角色，这样在以后的数据访问中，就可以根据改变后的角色进行数据的访问。使用这种方式，可以对数据进行细粒度的权限控制，例如数据库字段或文件中包含的内容等。４．２．ａ９级管理模式从对上面两种方式的分析可以看出，它们各自有优缺点，如何将以上两种方式的优点综合起来，避免它们的缺点是许多人研究的重点，我们也提出了一个分级管理方式的方案。在数据中心中，可以对资源进行粗粒度的权限控制，然后在系统内部可以增加细粒度的权限控制，而且系统内部是否进行细粒度控制是用户可以根据需求选择的。这种方式下的数据中心组织结构与以数据资源为中心的数据中心方式相同。只是数据资源可能是更粗粒度的，如系统，模块或目录，也可以是文件名等。在此管理方式下，访问控制可以分为两个步骤进行：首先进行粗粒度的权限控制，然后在系统内部根据条件重新确认用户的角色，并刑数据进行细粒度的权限控制。这种管理方式的优点是：可以灵活地控制用户对数据资源的访问权力。并且用户可以根据具体的情况分步骤实现系统，即可以首先进行粗粒度的权限控制，然后在此基础上通过对应用系统增加插件或修改系统实现更细粒度的权限控制。基于角色的访问控制（ＲＢＡＣ）及应用研究同时这种管理方式也存在与以用户资源为中心的管理方式一致的缺点：当用户需要对数据资源进行细粒度的权限控制时，必须对应用系统进行相应的修改。以上三种方式各有优缺点，究竟采用什么样的方式必须根据用户的具体需求来决定。无论采用什么样的方式，系统都可以灵话地支持以ｊ二三种管理方式，但目前只支持第一种以数据为中心的管理方式，如果要采用其他方式，必须根据应用系统的具体情况，对系统作出相应的修改。４．３ＲＢＡＣ典型应用之一－－Ａｐａｃｈｅ应用通过部署到企业的网络服务器，能够改进其信息服务的管理，增加其信息发布的安全性。通过提供一个易于部署和配置，．集成到当今专流ＷＥＢ服务器的访问控制平台，使企业可以放心地在网上发布信息，同时具有对不同角色赋予不同访问权限的能力。设计所要达到的目标：（１）与已有的Ａｐａｃｈｅ服务器结合．在整合原有认证（基础认证、基于数据库的认证、基于ＳＳＬ的认证等，并能够扩展到其他认证模式）的基础上，加入授权机制。（２）平台无关性，Ａｐａｃｈｅ服务器同时有ｗｉｎｄｏｗｓ和ＵｎｉＸ版本，开发出的产品与操作系统无关，但必须在不同的平台下重新编译。（３）与ＲＢＡＣ项目产品的整合。本产品对访问的控制（授权），应基于ＲＢＡＣ项目所定义的访问控制表，其接口和内容应完全遵从与目标对象的存储分离的权限控制文件方案。（４）可插拔的控制机制，对系统不希望进行访问控制的部分，可以通过设定，屏蔽访问控制。４．３．１总体设计４．３．１１处理流程下图说明了客户端发出请求后，服务端处理的流程。基于角色的访问控制（ＲＢＡＣ）及应用研究图４—４服务器处理流程如图４—４所示，当客户端发出ｈｔｔＰ请求，到达Ａｐａｃｈｅ服务器时，服务器会经过一系列的步骤来处理这个请求，当处理过程通过“预处理”、“用户认证”，到达“访问控制”是，服务器检测到我们注册的ＡＣＤＦ模块。如果用户访问的对象需要进行ＲＢＡＣ控制，则运行ＡＣＤＦ判决程序。此时，通过对用户名、对象名称和访问动作（读）的综合考察，得到是否允许的结论。如果允许访问，则按照一般的处理流程处理，否则，给出用户未授权的信息。对应下面图４—５的时序图可以更好地说明处理流程：囤匡三匡田匡习叵匡用户请求图４－５服务器处理流程时序图——一茎主鱼鱼塑堕塑量型！墨曼垒竺！塾窒旦婴塞４．３．１．２总体结构和模块外部设计本项目的总体结构可以参照本项目数据和控制流程图４—６来说明：望些堑ｆ封蕞戤掘ＵＲｒ｝ｊ：麓擀…』ｌ！！！一一…｜Ｉ！！塑！苎；２篱惫§＃ｊ图４－６Ａｐａｃｈｅ数据和控制流程图本项目分为三个模块：（１）Ａｐａｃｈｅ接口和配置负责声明相应的ｈｏｏｋ接口；提供项目相关的Ａｐａｃｈｅ配置命令及其处理函数；初始化各相关数据结构。（２）关键信息提取从Ａｐａｃｈｅ传入的结构数据中，得到用户名和访问对象信息：如果认证过程产生的用户名字段包含其他信息，则需要取出冗余信息，得到真实的用户名；如果访问对象表达不规范，则需要对该表达进行规范，以便于下一步的判决。（３）访问控制判决和处理（ＡＣＤＦ）通过查询ＲＢＡＣ数据库，实现ＡＣＤＦ功能。并根据返回的访问控制信息，采取相应的处理。从Ａｐａｃｈｅ服务器的角度来看，整个项目的处理流程如图４７：基于角色的访问控制（ＲＢＡＣ）及应用研究关键信息提取ｊ访问控制判决和处理模块声明、数据扔始化、处理配置阶段龠奇不同阶段的运行村接口服务器正常处理ＡｐａｃｈｅＪ］Ｒ务器（配置阶段）Ａｐａｃｈｅ服务器（运行阶段）图４—７处理流程Ａｐａｃｈｅ接口和配置：这部分负责声明相应的ｈｏｏｋ接口；提供项目相关的Ａｐａｃｈｅ配置命令及其处理函数：初始化各相关数据结构。Ａｐａｃｈｅ功能模块声明：Ａｐａｃｈｅ通过读取一个事先约定的数据结构，理解用户需要声明的功能模块的名称、各入口函数的位置等信息。ｍｏｄｕｌｅＡＰ—ＭＯＤＵＬＥ—ＤＥＣＬＡＲＥ—ＤＡＴＡｒｂａｃ—ａｕｔｈ—ｍｏｄｕｌｅ＝｛／／模块名称ＳＴＡＮＤＡＲＤ２０一ＭＯＤＵＬＥ—ＳＴＵＦＦ，ｃｒｅａｔｅ—ｒｂａｃ—ｄｉｒ—ｃｏｎｆｉｇ，ｒｂａｃ／／环境初始化函数ａｕｔｈｃｍｄｓ，／／配置文件命令实现函数／／服务器回调ｈｏｏｋｒｅｇｉｓｔｅｒ—ｈｏｏｋｓ，……（其他声明）对环境初始化、配置文件命令函数的实现。环境初始化主要任务是初始化本模块所需要的环境，申请可能需要的内存空间等；ｃＦｅａｔｅ＿ｒｂａｃ—ｄｉｒ—ｃｏｎｆｉｇ（）｛声明本模块将要用到的数据结构；ｉｆｉｆＪｒｂａｃ＝ｍａｌｌｏｃ（）：／／是否需要ｒｂａｃ控制；／／是否允许访问：ａｃｃｅｓｓ＝ｎｌａｌｌｏｃ（）：本模块定义Ａｐａｃｈｅ配置文件ｈｔｔｐｄ。ｃｏｌｌｆ中的命令ｒｂａｃ—ｃｏｎｔｉｌｏｌ，作用是控制是否进行ＲＢＡＣ访问控制。配置文件命令实现函数就是处理这个函数的功能；ｓｔａｔｔ６ｌｊｃＣｏｎｓｔｃｈａｒ｝ｃｏｉｌｔｒｏｌ（ａｒｇ）基于角色的访问控制（ＲＢＡＣ）及应用研究ｉｆｒｂａｃ＝ａｔｇ：／／ａｌ＂ｇ＝ＯＮ０ｒＯＦＦ）关键信息提取：从Ａｐａｃｈｅ传入的结构数据中，得到用户名和访问对象信息；如果认证过程产生的用户名字段包含其他信息，则需要取出冗余信息，得到真实的用户名；如果访问对象表达不规范，则需要对该表达进行规范，以便于下一步的判决。Ａｐａｃｈｅ维护了一个数据结构ｒｅｑｕｅｓｔ—ｒｅｃ记录处理当前请求的各种信息。该数据结构定义如下：／术水ＡＳｔｒＬｉｃｔｕｒｅｔｈａｔｒｅｐｒｅＳｅｌ３ｔｓｔｈｅＣｕｒＦｅｎｔｒｅｑｕｅｓｔ木／ｔＹｐｅｄｅｆｓｔｒｕｃｔｒｅｑｕｅｓｔ—ｒｅｃｒｅｑｕｅｓｔ—ｒｅｃ：ｓｔｒｕｃｔｒｅｑｕｅｓｔ—ｒｅｃ｛ａｐｔ—ｐ００１一ｔ＇ｌ＇ｐｏｏｌ：ｃｏｒｌｒｌｒｅｃ｝ｃｏｒｌｒｌｅｃｔｉｏｎ：ｓｅｒｖｅｒ—ｒｅｃ｛ｓｅｚ＇ｖｅｒ：ｒｅｑｕｅＳｔ—ｒｅｃ凇ｎｅｘｔ：ｒｅｑｕｅＳｔ＿ｒｅｃ＊ｐｒｅＶ：ｒｅｑｕｅｓｔｒｅｃ木ｍａｉｎ：ｃｈａｔ木ｔｈｅｒｅｑｕｅｓｔ：ｉｎｔａｓｓｂａｃｋｗａｒｄｓ：ｉｎｔｐｒｏｘＹｒｅｑ：ｉｎｔｈｅａｄｅｒｏｎｌＹ：ｃｈａｔ＊ｐｒｏｔｏｃｏｌ：ｉｎｔｐｒｏｔＯｉｌｕｍ：ｃｏｎｓｔｃｈａｔ＊ｈｏｓｔｒｌｉｌｍｅ：ａｐｒ—ｔｉｍｅ—ｔｒｅｑｕｅｓｔ—ｔｉｒｌｌｅ：ｃ０１１ｓｔｃｈａｒ｛Ｓｔａｔｕｓ１ｉｎｅ：ｉｎｔｓｔａｔｕｓ：Ｃｏｒｌｓｔｃｈａｔ％ｍｅｔｈｏｄ：ｉｎｔｍｅｔｈｏｄ—ｎｕｍｂｅｒ：ａｐｒｊｎｔ６４一ｔａｌｌｏｗｅｄ：ａｐｔ—ａｒｒａｙ—ｈｅａｄｅｒ—ｔ＊ａｌｌｏｗｅｄ—ｘｍｅｔｈｏｄｓ：ａｐ—ｍｅｔｈｏｄ—ｌｉｓｔｔ＊ａ１１０ｗｅｄ—ｍｅｔｈｏｄＳ：ａｐｔ—ｏｆｆ—ｔｓｅｎｔ—ｂｏｄｙｃｔ：ａｐｔ—ｏｆｆ—ｔｂＹｔｅｓｓｅｎｔ：６２基于角色的访问控制（ＲＢＡＣ）及应用研究ａＤｒｔｌｎｌｅｔｍｔｌｍｅ：Ｉｎｔｃｈｕｎｋｅｄ：ＣＯｎＳｔｃｈａｒ％ｒｆｌ．ｎｇｅ：ａＤｒ０ｆｆｔｃｌｅｎｇｔｈ：ａＤｒ０ｆｆｔｒｅｌｎＥｉ，ｉｎｉｔ３９：ａＤｒ０ｆｆｔｒｅａｄｊｅｎｇｔｈＩｎｔｒｅａｄｂｏｄＹ：１ｒｌｔｒｅｌ９．ｄｃｈＵｎｋｅｄＵｎＳｌｇｒｌｅｄｅＸｐｅｃｔｉｎｇ一１００；ａＤｒｔａｂｌｅ—ｔ＊ｈｅａｄｅｒｓ—ｉｒｌ：ａＰｒ—ｔａｂｌｅ—ｔ＊ｈｅａｄｅｒｓｏｕｔ：ａｐｒ—ｔａｂｌｅ—ｔ＊ｅｒｒ—ｈｅａｄｅｒｓｏｕｔａｐｒ—ｔａｂｌｅ—ｔ｝ｓｕｂｐｒｏｃｅｓｓ—ｅｎｖ：ａｐｒ—ｔａｂｌｅ—ｔ木ｎＯｔｅｓ：Ｃ０ｎＳｔｃｈａｒ木ｃ０１３ｔｅｎｔ—ｔｙｐｅ：Ｃ０ｎＳｔｃｈｆ９．ｒ｝ｂａｎｄｌｅｒ：Ｃ０ｎＳｔＣｈａｒｔｏｌｌｔｅｒｌｔ—ｅｌｌｃｏｄｉｎｇ：ａＤｒａｒｒ￡１．ｙ—ｈａｄｅｒ—ｔ｛ｃｏｒｌｔｅｒｌｔ—ｌａｎｇｕａｇｅｓＣｎａｒ｝Ｖ１ｉｓｔｖａｌｉｄａｔｏｒＣｈａｒ木ＬＩＳｅｒ：ｃｈａｒ＊ａｐ—ａｕｔｈ—ｔｙｐｅｉｎｔｎ０Ｃａｃｈｅ：ｉｎｔ１１０１０ＣａｌｃｏＰＹ：Ｃｎａｒ％ＵｎｐａｒＳｅ０ＵｒｌＣｈａｒ｝ｕｒｉ：ｃｈＥＬｆ｝ｆｉｌｅｎｉｇ，ｍｅ：Ｃｎａｒ木ｃ８．１１０１３．ｉＣａｌ—ｆｉｌｅｒｌａｍｅＣｎａｒ＊ｐａｔｈ—ｉ１１ｆｏ：Ｃｎａｒ｝ａｒｇｓ：ａｐｔ—ｆｉｎｆｏ—ｔｆｉｎｆｏ：ａｐｒ—ｕｒｉ—ｔｐａｒＳｅｄ—ＵｒｉｉｒｌｔＵＳｅｄ—ｐａｔｈ—ｉｎｆｏ：ｓｔｒｕｃｔａｐ—ｃｏｎｆ—ｖｅｃｔｏｒ—ｔ｝ｐｅｒ—ｄｉｒ—ｃｏｎｆｉｇｓｔｒｕｃｔａｐ—ｃｏｎｆ—ｖｅｃｔＯｒ—ｔ＊ｒｅｑＬｌｅｓｔ—ｃｏｎｆｉｇ６３基于角色的访问控制（ＲＢＡＣ）及应用研究ＣＯＦＩＳｔｓｔｒｕｃｔｈｔａｃｃｅｓｓ＿ｒｅｓｕｌｔ水ｈｔＥｔｃｃｅｓｓ：Ｓｔｒｕｃｔａｐ—ｆｉｌｔｅｒ—ｔ木ｏｕｔｐｕｔ—ｆｉｌｔｅＦｓ：ｓｔｌ＂１３Ｃｔａｐ—ｆｉｌｔｅｌ＂一ｔ％ｉｎ！ｏｕｔ—ｆｉｌｔｅｒｓ：ＳｔｒｕＣｔａｐ—ｆｉｌｔｅｒ—ｔ＊ｐｒｏｔ０ＯＵｔｐｕｔ—ｆｉｌｔｅｒｓ：ｓｔＩ＇ＬｌＣｔａｐ—ｆｉｌｔｅｒ—ｔ＊ｐｒｏｔ０一ｉｎｐｕｔ—ｆｉｌｔｅＩ＂ｓ：ｉｎｔｅｏｓ—ｓｅｎｔ：）：这是一个很复杂的ＳｔＬｌｒＣｔ，记录了当前请求（ｒｅｑｕｅＳｔ）相关的各方面的信息，服务器处理请求时，处理的结果也放在其中。例如，当认证过程成功后，Ａｐａｃｈｅ会将用户名数据存放在“ｕｓｅｒ”中，这样在授权阶段，我们就可以从中提取出用户名数据，以便进行下一步的处理。所以，“ｕｓｅｒ”字段既是结果的存放地，也是数据的提取处。若要了解关于ｒｅｑｕｅｓｔ—ｚＦｅｃ的具体细节，请参见Ａｐａｃｈｅ的相关文档和ｈｔｔｐｄ．ｈ。只要我们在合适的时候截获Ａｐａｃｈｅ的控制，就能够获得用户名信息。当然，我们也可以自己从初始的ｈｔｔｐ请求中获取一切信息，但这样既增加的程序的复杂度，又不利于系统的灵活性：我们希望可以灵活的替换访问控制模块，只要访问控制模块将得到的用户名放入ｒｅｑｕｅｓｔ—ｒｅｃ，我们直接从ｒｅｑｕｅｓｔ—ＺＦｅＣ中提取信息．而不必关心究竟用户名是怎样得到的。访问控制判决和处理。通过查询ＲＢＡＣ数据库，实现ＡＣＤＦ功能。并根据返回的访问控制信息，采取相应的处理。这是整个项目的核心，也是ｒｅｇｉｓｔｅｒ—ｈｏｏｋｓ（服务器回调ｈｏｏｋ）需要调用的功能。ｉｎｔａｃｄｆ（ｕｓｅｒｎａｎｌｅ，ｏｂＪｅｃｔｎＥｔｌＩｌｅ，ｏｐｅｒａｔｉｏｎ）／／输入参数：用户名、对象名、操作｛ｉｆ（！ｉｓ—ＬＩｒｉ（ｏｂｊｅｃｔｎａｍｅ））ｏｂｊｅｃｔｎｉｊｍｅ＝ｕｌ－ｉ（ｏｂｊｅｃｔＥｌＥｔｍｅ）：／／根据需要，对对象名进行标准化处理０ｂＪｅＣｔ＿ｃｏｎｔｒ０１一ｄａｔａ＝ｗｈｅｒｅｉＳ—Ｃ０１１ｔｒ０１一ｄａｔａ（０ｂＪｅＣｔｉｑａｉｉｌｅ）；／／对象的控制信息在哪里ｉｆ（！ｅｘｉＳｔ（ｏｈＪｅｃｔ—ｃｏｎｔＩ＇０１一ｄａｔａ））ｒｅｔｕｒｎ一１：／／“一１”表示没有对象的控制信息ＣＯｒｌｔｒｏｌ—ｄａｔａ＝ｃｏｎｔｅｎｔ—ｏｆ（ｏｂｊｅｃｔ—ｃｏｎｔｒ０１ｄａｔａ）：基于角色的访问控制（ＲＢＡＣ）及应用研究／／打开控制信息ｉｆ（！ＵＳｅｒ—ｉｎ（ｕｓｅｒｎａｍｅ，ＣＯｎｔｒｏｌ—ｄａｔａ））ｒｅｔｕｒｎ一２：／／“一２”表示用户对对象没有控制ｉｆ（！ｏｐｅｒａｔｉＯｉｌ—ｏｆ—ｕｓｅｒ（ｕｓｅｒｎａｍｅ，ｃｏｎｔｒｏｌ—ｄａｔａ，ｏｐｅｒａｔｉＯＩｑ））一３：／／“一３”表示用户的权限不足／／成功，用户可以访问对象４．３１．３接口设计本应用没有用户界面和接口。本应用和ＲＢＡＣ项目的接口就是ＲＢＡＣ数据库。由于本项目的实施完全依赖于该数据库，因此本项目实施过程中，涉及该数据库的操作一定要准确按照设定的标准来执行。包括角色定义、用户定义、用户角色的映射关系，以及角色对不同目录的访问权限数据。关于该数据库的数据结构和安排，参见ＲＢＡＣ项目相关文档。接口设计包括：（１）内部接口本应用内部接口包括：包含本次ｈｔｔＰ请求及处理信息的Ｓｔｒｕｃｔｒｅｑｔｉｅｓｔｒｅｃ、ＡＣＤＦ函数的访问接口等，这些在前面的说明中已经包括，这里就不再赘述。流程图参见下图４—８：图４—８流程图（２）运行控制本模块的运行受Ａｐａｃｈｅ服务器整体调度，除了对Ａｐａｃｈｅ服务器进行启动、停止和重启之外，用户无法对其进行控制。（３）运行时间本模块的运行受Ａｐａｃｈｅ服务器整体调度，其运行时间也受Ａｐａｃｈｅ服务器控制。在需要进行ＲＢＡＣ控制的请求到达后，本模块将在Ａｐａｃｈｅ基于角色的访问控制（ＲＢＡＣ）及应用研究的整个处理过程中占用一定的时间，其具体比例视具体的请求而定。４．４ＲＢＡＣ典型应用之二一在数据库中的应用４．４．１工程背景按照中纪委的目标，建成全新的信访举报管理系统，这套系统采用Ｂ／Ｓ模式，并建立在认证和授权这个安全基础设施上，基础设施必须先搭建，然后在此基础上构建应用系统。４．４，２系统分析中纪委目前的这套信访举报管理ＤＥＭＯ系统采用ＶＢ作为开发语言，后台连接ＳＱＬＳＥＲＶＥＲ数据库，利用ＯＤＢＣ进行数据访问。完成的工作基本可以抽象成固定化的工作流系统：从信件录入、批复、办理到最后结案（大约是这样），在应用界面上能够进行相应的操作；值得注意的是，在原系统已经有一定的认证和授权功能。为了尽快拿出我们的ＤＥＭＯ，我们应该将重点放在对数据库数据的访问控制上，因为第一、数据库内容才是访问控制的对象，第二、很多对访问控制的需求实际上可以转化成对数据库数据的访问控制。其他要求例如对界面按钮的控制（显示或激活），这是系统功能方面的要求，可以先不考虑。现有的ＲＢＡＣ是在访问对象是文件的基础上开发的，现在访问目标变成了数据库记录，原有系统的一部分不能用了，此外还要改变一部分．增加一些功能。（１）ＲＢＡＣ系统的相关功能・角色管理即对角色的层次关系进行配置的用户界面，最后得到～棵类似树状的角色关系图。・资源列表获取用户需要将数据库中的记录形成资源列表导出，具体是对每这个标识符。・角色一资源绑定条记录形成一个唯一的标识符（比如该记录的ｋｅｙ），以后进行判断时就利用将角色和资源通过操作权限绑定起来，形成角色的权限集。６６基于角色的访问控制（ＲＢＡＣ）及应用研究●用户一角色绑定赋予用户一定的角色，用户就可以通过角色的权限，获得对资源的权限。（２）ＲＢＡＣ在数据库中的设计・ＡＣＬ动态更新ＡＰＩ由于加入或删除数据项后，需要对ＡＣＬ进行同步，这件事必须在应用中对数据记录进行增、减的同时进行，所以只能提供ＡＰＩ，供应用自己调用，以更新ＡＣＬ数据。・对用户读操作的考虑用户读操作会使用“ＳＥＬＥＣＴ”语句，返回的将是一系列的记录。处理方法是：在原应用程序ＳＥＬＥＣＴ返回查询结果后，插入一条“ｆｉｌｔｅｒ’函数，该函数对返回结果的每一条使用ＲＢＡＣ基本判决函数进行过滤，删除用户权限不能察看的记录，留下用户能够察看的部分。这样达到对数据库记录读操作进行ＲＢＡＣ访问控制的目的。●对用户写操作的考虑用户对数据表的写操作一般有两种：添加记录或者修改记录。添加记录由于ＡＣＬ中本来没有新添加的这一项的授权信息，因此添加操作时的判断应该在对数据表本身是否能写，而不是数据表中的某一项记录。这就要求在资源列表形成的时候，对数据表本身专门列出以便对数据表进行插入操作。修改记录比较简单，由于ＡＣＬ中本身已经有该项的授权信息，直接进行判断就行。需要考虑的是可写授权如何进入ＡＣＬ的问题。在角色一资源绑定中可以进行配置，而在新增记录时可能要求同时某人对这项记录有了读写权限，这在ＡＣＬ动态更新中需要注意。还需要提到的是，如果用户希望新增记录时，自动拥有权限的用户和拥有哪些权限是可配置的，这会大大加重ＡＣＬ动态更新部分的工作。项，４．５本章小结本章介绍了应用中集中权限管理的优势、访问控制使用的三种集中管理模式，以及两个典型的应用，说明ＲＢＡＣ在应用中确实是有广阔的应用前景。基于角色的访问控制（ＲＢＡＣ）及应用研究第五章论文总结与工作展望随着Ｉｎｔｅｒｎｅｔ的迅猛发展，信息共享的程度进一步提高，数字信息越来越深入的影响着社会生活的各个方面，而网络上的信息安全问题也目益突出。访问控制技术是信息安全的一项基本技术，而ＲＢＡＣ解决了传统访问控制技术的不足，借助于角色这个主体，将原来成千上万的用户抽象成角色，用户通过角色访问资源，建立这样一种映射关系，大大提高了管理的效率。本项目实现了可视化角色编辑工具、用户授权管理工具、ｕＲｌ权限管理工具、测试工具、日志管理工具、集成管理工具、ＵＲＩ列表生成工具、特别是为应用提供访问控制接口（ＡＣＤＦ）模块。应用可以通过本项目提供的工具对用户、角色、权限进行管理和控制，尤其通过简单易用的二次编程接口实施最终的访问控制。在实际的应用中，本项目的成果得到了很好的应用，确实较好的解决了应用中的访问控制的管理问题，当然由于本项目对一些复杂的规则进行了裁减，因此在较为复杂的系统中，成果的应用受到了一定的限制。在今后的发展中，本项目可以在动态继承、多继承、对应用的支持方面继续研究。基于角色的访问控制（ＲＢＡＣ）及应用研究致谢我首先要感谢我的导师，电子科技大学计算机学院的傅彦教授和卫士通的总工谭兴烈研究员。作为二位老师的硕士研究生，我得到了二位老师在学习和工作等各方面的悉心指导，使我受益匪浅。此外，我还要感谢电子科技大学计算机学院余垄副教授。余老师在我的毕业设计和工作中。给我细心的指导和帮助，使我更加丰富了信息安全等许多领域的知识。最后，我还要感谢在我毕业设计期间和我一起工作的同事、同学和朋友们，没有他们的帮助和配合，我不可能顺利的完成此次毕业设计。６９基于角色的访问控制（ＲＢＡＣ）及应用研究参考文献【１］ＪｏｈｎＢａｒｋｉｅｙ．ＲＯＬＥＢＡＳＥＤＡＣＣＥＳＳＣＯＮＴＲＯＬ．ＳｏｆｔｗａｒｅＤｉａｇｎｏｓｔｉｃｓａｎｄＣｏｎｆｏｒｍａｎｃｅＴｅｓｔｉｎｇＮａｔｉｏｎａｌＩｎｓｔｉｔｕｔｅｏｆＳｔａｎｄａｒｄｓａｎｄＴｅｃｈｎｏｌｏｇｙ．１９９７【２］ＤａｖｉｄＦ．Ｆｅｒｒａｉｏｌｏ，ＪｏｈｎＦ．Ｂａｒｋｌｅｙ，ａｎｄＤ．ＲｉｃｈａｒｄＫｕｈｎＡｃｃｅｓｓＣｏｎｔｒｏｌＡＲｏｌｅａＢａｓｅｄＭｏｄｅｌａｎｄＲｅｆｅｒｅｎｃｅＩｍ口１ｅｍｅｎｔａｔｉｏｎｗｉｔｈｉｎＣｏｒｐｏｒａｔｅＩｎｔｒａｎｅｔ．ＮａｔｉｏｎａｌＩｎｓｔｉｔｕｔｅｏｆＳｔａｎｄａｒｄｓａｎｄＴｅｃｈｎｏｌｏｇｙ，１９９９．【３］Ｔｏｎｙ２０，１９９８Ｃｉｎｃｏｔｔａ，ＳｅｒｂａｎＧａｖｒｉｌａ，ＪｏｈｎＢａｒｋｌｅｙ．“ＲＢＡＣ／ＷｅｂＲｅｌｅａｓｅ１．１”Ｍａｙ【４］Ｊａｅｑｅｒ，ｔ．Ｏｎｔｈｅｉｎｃｒｅａｓｅｄｉｎｐｏｒｔａｎｃｅｏｆｃｏｎｓｔｒａｉｎｔｓ．ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅｏｎＦｏｕｒｔｈＡＷｏｒｋｓｈｏｐＲｏｌｅ－ＢａｓｅｄＡｃｃｅｓｓＣｏｎｔｒｏｌ（Ｏｃｔ．），Ｉ９９９．［５】ＤａｖｉｄＦ．Ｆｅｒｒａｉｏｌｏ，ＲａｖｉＡｃｃｅｓｓＳａｎｄｈｕ，ＳｅｒｂａｎＯａｖｒｉｌａ，ＰｒｏｐｏｓｅｄＮ１ＳＴＳｔａｎｄａｒｄｆｏｒＴｒａｎｓａｃｔｉｏｎｓｏｎＲｏｌｅ—ＢａｓｅｄＣｏｎｔｒ０１．ＡＣＭＩｎｆｏｒｍａｔｉｏｎａｎｄＳｙｓｔｅｍＳｅｃｕｒｉｔｙ，Ａｕｇｕｓｔ２００１，Ｖ０１．４，Ｎｏ．３．ｆ６】林磊，骆建彬，等．管理信息系统中基于角色的权限控制【Ｊ］．计算机应用研，２００２，１９（６）：８２—８４．【７】姜志红，须德．基于Ｗｅｂ的信息系统的用户权限设置策略【Ｊ】．北京交通大报，２００１，２５（２）：３３－３６．【８］ＲａｖｉＳａｎｄｈｕ，ＶｅｎｋａｔａＢｈａｍｉｄｉｐａｔｉ，ＱａｍａｒＭｕｎａｖｅｒ．ＴｈｅＡＲＢＡＣ９６ｍｏｄｅｌｒｏｌｅｓ【Ｊ］．ＡＣＭＴｒａｎｓａｃｔｉｏｎｓｏｎｆｏｒｒｏＩｅ－ＢａｓｅｄａｄｍｉｎｉｓｔｒａｔｉｏｎｏｆａｎｄＳｙｓｔｅｍｌｎｆｏｒｍａｔｉｏｎＳｅｃｕｒｉｔｙ，１９９９，２（１）：１０５－１５３．ＲＢＡＣｏｎａ【９］Ｊｈｏｆｆｍａｎ．Ｉｍｐｌｅｍｅｎｔｉｎｇｔｙｐｅｅｎｆｏｒｃｅｄｓｙｓｔｅｍ［ｃ］ｌ５８－Ｐｒｏｃｏｆｔｈｅｌ３ｔｈＡｎｎｕａｌＣｏｍｐｕｔｅｒＳｅｃｕｒｉｔｙＡｐｐｌｉｃａｔｉｏｎ１６３Ｃｏｎｆ（ＡＣ’９６），Ｉ９９６１［１０］李孟珂，余祥宜．基于角色的访问控制技术及应用【Ｊ】．计算机应用研究．２０００，（１０）：４４－４７．［１１］乔颖，须德，戴国忠．一种基于角色访问控制（ＲＢＡＣ）的新模型及其实现机制［Ｊ】．计算机研究与发展，２０００，３７（１）：３７—４４．［１２］ＤａｖｉｄＰｒｏｃｅｅｄｉｎｇｓＦｅｒｒａｉｏｌｏｏｆｌ５ｔｈａｎｄＲｉｃｈａｒｄＫｕｈｎ．Ｒｏｌｅ－ｂａｓｅｄＮａｔｉｏｎａｌＣｏｍｐｕｔｅｒａｃｃｅｓｓｃｏｎｔｒｏＩＳ１１３ＮＩＳＴ—ＮＣＳＣＳｅｃｕｒｉｔｙＣｏｎｆｅｒｅｎｃｅ，Ｏｃｔｏｂｅｒ１９９２：５５４－５６３．［１３］ＩｍｔｉａｚＭｏｈａｍｍｅｄａｎｄＤａｖｉｄＭ．Ｄｉｉｔｓ．Ｄｅｓｉｇｎｆｏｒｄｙｎａｍｉｃｕｓｅｒ－ｒｏｌｅ。ｂａｓｅｄｓｅｃｕｒｉｔｙ．Ｃｏｍｐｕｔｅｒｓ＆Ｓｅｃｕｒｉｔｙ，１９９４，１３（８）：６６１－６７１．７０基于角色的访问控制（ＲＢＡＣ）及应用研究【１４］ＲａｖｉＳ．Ｓａｎｄｈｕ．Ｌａｔｔｉｃｅ－ｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏＩｍｏｄｅｌｓ．ＩＥＥＥＣｏｍｐｕｔｅｒ，ＮｏｖｅｍｂｅｒＩ９９３，２６（１１）：９－１９．［１５】ＲａｖｉＳ．Ｓａｎｄｈｕ，ＥｄｗａｒｄＲｏｌｅ－ｂａｓｅｄａｃｃｅｓｓｃｏｎＪＣｏｙｎｅ，ＨａｌＬ．Ｆｅｉｎｓｔｅｉｎ，ａｎｄＣｈａｒｌｅｓＥ．ＹｏｈｍａＤＩＥＥＥＣｏｍｐｕｔｅｒ，Ｆｅｂｒｕａｒｙ１ｔｒｏｌｍｏｄｅｌｓ９９６，２９（２）：３８—４７［１６］ＣｈａｒｉｅｓＹｏｕｍａｎ，ＥｄＣｏｙｎｅ，ａｎｄＲａｖｉＳａｎｄｈｕ，ｅｄｉｔｏｒｓ．Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅｏｎ２ｎｄＡＣＭＷｏｒｋｓｈｏｐＲｏｌｅ－ＢａｓｅｄＡｃｃｅｓｓＣｏｎｔｒｏｌ，１９９７．ｅ［１７】Ｃｈａｒｌｅｓ３ｒｄＡＣＭＹｏｕｍａｎ，ＥｄＣｏｙｎｅ，ａｎｄＲａｖｉＳａｎｄｈｕ，ｅｄｉｔｏｒｓ．ＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｏｎＷｏｒｋｓｈｏｐＲｏｌｅ－ＢａｓｅｄＡｃｃｅｓｓＣｏｎｔｒｏｌ，１９９８．［１８］Ｗ．Ｅｓｓｍａｙｒ，Ｇ．Ｐｅｒｎｕｌ，ａｎｄＡ．Ｍ．Ｔｊｏａ．Ａｃｃｅｓｓｃｏｎｃｅｐｔｓ．Ｐｒｏｅ．ｏｆ１１ｔｈＡｕｇｕｓｔ１９９７ＩＦＩＰｃｏｎｔｒｏｌｓｂｙｏｂｊｅｃｔ－ｏｒｉｅｎＩｅｄＷＧ１１．３ＷｏｒｋｉｎｇＣｏｎｆ．ｏｎＤａｔａｂａｓｅＳｅｃｕｒｉｔｙ，【１９］Ｄ．Ｆ．Ｆｅｒｒａｉｏｌｏ，Ｊ．Ｆ．ＢａｒｋＩｃｙ，ａｎｄＤ．Ｒ．ＫｕｈｎｍｏｄｅｌａｎｄｒｅｆｅｒｅｎｃｅｏｎＡＲｏｌｅ－ＢａｓｅｄＡＣＣｅＳＳＣｏｎｔｒｏｌａｉｍｐｌｅｍｅｎｔａｔｉｏｎａｎｄＳｙｓｔｅｍｗｉｔｈｉｎｃｏｒｐｏｒａｔｅＩｎｔｒａｎｅｔＡＣＭＴｒａｎｓａｃｔｉｏｎｓ３４－６４ＩｎｆｏｒｍａｔｉｏｎＳｅｃｕｒｉｔｙ，Ｆｅｂ．１９９９，ＶｏＩ．２，Ｎｏ．１：［２０］ｗ．Ａ．Ｊａｎｓｅｎ．ＡＲｅｖｉｓｅｄＭｏｄｅｌｆｏｒｒｏｌｅ－ｂａｓｅｄＡｃｃｅｓｓＣｏｎｔｒｏｌＪｕｌｙ９，１９９８【２１］ＲａｖｉＳ．Ｓａｎｄｈｕ，ＥｄｗａｒｄＪ．Ｃｏｙｎｅ，ＨａｌＡｃｃｅｓｓＣｏｎｔｒｏｌＬ．ＦｅｉｎｓｔｅｉｎａｎｄＣｈａｒｌｅｓＥ．Ｙｏｕｍａｎ１９９６．ＲｏＩｅ—ＢａｓｅｄＭｏｄｅｌｓ．ＩＥＥＥＣｏｍｐｕｔｅｒ，ＦｅｂｒｕａｒｙＶｏｌｕｍｅ２９（Ｎｕｍｂｅｒ２）．７