0 引言
目前多数实际应用系统的安全功能模块都采用内嵌业务模块的方式开发实现，安全组件和业务组件耦合度过高，导致两者之间的交互关系繁杂，功能逻辑抽离性差；另外，安全系统涉及认证、授权、访问控制和责任认定等领域，现有的集中开发模式没有从软件形态、逻辑形态以及最后的物理形态上对安全组件进行进一步构件化分离，造成部件功能划分模糊重叠，不易开展安全功能专有评测，二次开发代价高、周期长、风险大。
1 相关工作发展现状
网络应用的高速发展和分布式服务的不断深入使得系统安全产品从封闭型、单体化的形态向协作型、可插拔的中间件模式转变。近年来，国际上已涌现出一批具有影响力的安全中间件项目。耶鲁大学开发的CAS，Internet2/Mace和IBM开发的Shibboleth，英国Kent大学开发的PERMS，美国NASA开发的Cardea等都采用了面向专有安全功能开发的中间件形式。提供针对单一需求的安全服务。但是这些中间件系统内部构件化和可替换性还处在粗粒度的发展阶段，封装的算法和协议层次单一，无法适应企业应用对安全功能定制的裁剪性和敏捷性需求。基本上没有提供面向安全开发人员或者业务涉及人员进行多次开发、自由组装的平台和方法。
还有一些旨在提供基础性安全技术的开发包，例如Bouncy Castle Crypto、Crypto++、IAIK Crypto等，这些项目可以提供全面丰富的密码算法具体实现、公钥/属性证书生成器、密码学相关数学工具。已经在很多实际系统作为安全基础设施大量应用，但其两个基本不足在于：开发包内部结构仍然比较复杂，即使面向专业人员的学习曲线仍然较高；缺乏构建上层安全集成服务的组装模式和开发模版，不能提供直接面向业务安全的功能接口，后期的开发量仍然较大。
2 基于共性安全构件的安全业务建模
本文提出的共性安全构件，又称为信息安全共性构件，旨在将安全功能从传统的业务逻辑中分离，进而分割成具有不同安全子功能的模块，各模块对外提供接口，获得可独立开发，可方便组装、拆解、更换的优势。共性安全构件提供良好的扩展性，可以用于快速便捷地搭建安全系统，从而实现安全系统自底向上的，配置型可定制性开发。
2.1 共性安全构件三层结构
共性安全构件可以按其实现完整功能的复杂度划分到三个不同层次的子集中。基础构件只实现一个具体算法或者定义具体的算法结构，处于最底层；功能构件由基础构件搭建而成，能独立提供一种安全业务功能；服务构件由基础构件和功能构件搭建而成，实现一套完整的安全业务，并能以web服务的形式供外部调用。
2.2 基于服务构件的安全业务建模方法
共性安全构件的开发是从底层基础构件到中层功能设施构件然后到上层的集成服务构件，而业务流程的开发是从上层业务建模到中层的过程分析然后到底层的服务集成，这是两个不同方向的开发。
现有系统的安全功能开发往往局限于具体的安全事务，缺乏从安全业务的角度考虑流程安全完整性。本文从已有的应用业务中抽取并设计了一个完整的安全访问业务流程，利用BPEL编排将构件开发与业务流程开发无缝地结合起来，形成完善的安全业务流程的开发模式。
BPEL是为整合web服务而制定的一种标准规范，它可以在不影响原有web服务正常运行的前提下，将web服务进行调度和协调，从而形成具有商业价值的业务流程。在基于服务构件的安全业务流程开发过程中引入BPEL语言，可有效提高安全系统开发的效率。
安全访问业务流程主要包括安全认证，授权与访问控制，审计与责任认定三大处理流程。在这些处理流程之下，还集成了域定位服务、认证服务、跨域身份联合服务、断言服务、策略查询服务、属性查询服务、审计记录服务等跨域或单域访问过程中需要的web服务，能够提供一套完整的安全访问业务流程所需的各种功能。以下通过访问控制流程的实施步骤和其中涉及的子流程给出完整的实现步骤说明。
访问控制流程是从业务的角度利用BPEL建模工具对服务构件进行粘合从而实现灵活的安全访问控制系统。整个流程包含了一个总的访问控制过程，包括认证，授权以及审计部分。每一个功能的具体实现都封装在所调用的服务构件中。流程中不包括细粒度的安全处理过程。
BPEL流程的执行过程描述采用了程序设计语言伪代码的方式，其中变量和方法的命名都采用了统一的形式，目的是使流程的执行过程表述更加清晰，是实际BPEL流程建模和执行过程的抽象描述。
BPEL流程中调用的每一个web服务可以是由web服务粘合而成的子流程，例如对访问控制流程中的Authentication Enforce Service，可以采用BPEL流程进行建模，如图1所示。
图1 BPEL建模的安全认证过程流程图
这样，我们利用BPEL自上而下地从业务流程的角度构建了一个安全访问控制系统模型。通过这种方式，可以从很大程度上避免对底层细节的处理，这些细节可以交给具体的web service以构件的形式进行封装。由于不涉及到细节处理。可以使流程的执行逻辑更加严密，从更大程度上减少系统的安全漏洞和隐患。同时由于web service可以根据需要而更换，系统的升级和更新将更加方便，减少了系统维护的代价。
2.3 共性安全构件组装开发技术
AOP和DI技术是软件工程领域成熟的开发方法。它们面向接口和对象，采用程序设计语言提供的反射机制实现系统的动态部署和功能替换。
本文从构件的层面，将AOP和DI思想引入到共性安全构件的组装开发过程中，将提供类似功能的构件归类，抽取通用的操作接口。上层构件对底层构件的调用采用松散耦合机制，对易变的底层构件调用其接口，具体构件在部署时由配置文件指定，这样可以有效提高构件的复用性，同时加快构件部署系统时的效率和灵活性。下面结合属性检索构件说明如何将AOP和DI的思想结合到共性安全构件的开发过程中及其带来的优势。
在传统的访问控制模型中，属性检索必不可少。通常需要根据用户的属性信息来为其提供相应的访问权限。但是在不同的应用场景下，不同的对象属性检索方式可能不同。如果在设计一个访问控制系统的时候，使用哪种属性检索方式还不确定，通常的做法将会是将所有的属性检索构件全部集成到其中，然后根据用户提供的消息来决定使用哪一个构件，正如图2中所描述。这与设计安全构件的初衷相背离。用安全构件搭建系统的优势就是构件可方便进行拆解和组装，易更换和升级。
图2 集成式属性检索构件
下面结合AOP和DI思想，提供一种更好的解决方案。图3显示了重新设计的属性检索构件架构，首先提取出所有属性检索过程所需要的操作，然后将这些操作封装成一个接口Attribute Retrieve Faetory。每个属性检索构件都实现该接口，遵循该接口定义的规范。系统开发时针对接口进行编码，运行时根据配置文件，采用面向对象语言的反射机制注入实际需要的具体属性检索构件。每一个属性检索构件只要实现了该接口，就可方便地组装到系统中。这样既可简化系统架构，又有利于系统的扩展，方便新的属性检索构件的开发和配置。
图3 采用AOP和DI思想实现的遁用属性检索构件
在创建构件的过程中，合理地使用AOP和DI思想可以带来很大的方便。虽然采用反射机制在运行时创建对象会带来一定的效率损失，但是可以简化系统架构，优化配置过程，更重要的是使系统的扩展、构件的开发应用更加方便快捷。反射机制和对象的动态生成功能在静态面向对象语言如Java、C#中都已经提供了一定的机制来实现，可以较方便地将其应用到构件开发应用中。依赖注入结合AOP思想的开发技术，可以将构件之间的继承关系和共性特征很好地展现出来，使构件层次划分、类别划分更加清晰，也更容易实现构件的开发、组装、扩展和升级。图4描述了基于AOP和DI思想的安全构件组装开发模式。
图4 基于AOP和DI思想的安全构件组装开发模式
3 性能测试与实验数据
本节从系统性能方面，针对之前设计的安全业务流程中安全认证系统进行测试，获取试验数据并与传统的安全认证中间件产品CAS、OpenID协议进行比较，验证安全构件集成建模方法的有效性。为了使系统之间更具可比性，本文只针对服务端一次成功验证的时间进行比较，时间的截取从认证信息发出到认证断言颁发成功为止，采用统一的用户名口令认证方式。同时为了减少网络IO对传输速率的影响，认证系统都采用本地部署的方式，并且CAS和OpenID协议都采用单域的认证机制，以减少跨域流程带来的性能损失，防止其对比较结果产生影响。安全认证系统的BPEL流程图如图6所示，它包含了可用的四种具体认证方式。本节只对用户名口令认证方式进行测试。其他三种方式的认证服务构件并未实现。但是为了使比较结果更加趋于实际应用，流程中保留了分支活动。为此，安全认证BPEL流程接受的输入参数除了包含用户名、口令之外，还有所选择的认证方式标识，如图5所示。
图5 安全认证系统输入参数
CAS和OpenID的基本认证流程如图6所示，本试验为减少实验环境对测试性能的影响，将客户端、依赖方、认证服务器部署到统一机器上，并且只统计认证服务器进行认证的时间，即图6流程中从客户端发送用户身份数据(步骤3)到依赖方收到认证结果(步骤4)之间的时间。
图6 CAS和OpenID的基本认证流程
本文利用3GHz主频、2G内存的计算机，部署了CAS 3.0服务、OpenID服务以及安全认证系统，采用本地MySql身份数据库，针对一次成功的单域认证所用的时间，对三个系统性能进行比较分析，另外还对安全认证系统内的用户名口令认证服务构件做了测试，以此分析基于BPEL构件整合方案的性能损耗。具体数据见表1所示。
表1 各认证系统性能数据比较
通过上述数据可以看出，基于安全服务构件搭建的安全认证系统在效率上较CAS和OpenID更为出色，但是与直接使用口令认证服务构件进行认证的效率相比，却存在一定差距。根据认证流程可以分析得出，这部分效率损失主要集中在web Service接口调用时，对数据的xml编解码过程之中。由此可见，使用BPEL粘合服务构件搭建安全业务系统，是以部分性能损耗为代价，换取高效的开发、灵活的部署方式，在很多场景下是具有实际应用价值的。
为了提高安全业务系统的效率，可以增加安全服务构件的粒度，减少安全业务流程中web service的调用次数；此外，研发更加高效的安全服务构件粘合技术是解决该问题最直接的手段。
4 结语
本文试图介绍一种新型的建模方法，通过将AOP和BPEL等软件开发技术和思想结合到信息安全共性构件的开发和应用中，使信息安全系统的建模过程更加方便，从上层而言避开了琐碎的实现技术细节，所建立的系统逻辑清晰，从而减少了系统中存在的安全漏洞，具有更高的安全性能。同时从底层而言由于信息安全共性构件的使用，系统的可重用性大大提高，用户可以根据实际需要更换相应的构件，具有良好的扩展性，系统的维护和更新更加便捷。
从长远来看，云计算、服务托管是近来新兴的业务模式和网络应用层体系结构。由此产生出新的安全需求和安全问题。包括策略集成在内的诸多安全技术应更好地借助共性安全构件这一先进开发理念，从新的业务角度出发，重新定位受保护的核心资产和安全目标实施方式．提供与产业应用升级同步的安全服务模式升级。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：基于服务构件集成的安全访问业务建模方法
相关文章
