基于产品思想的RA系统高效定制开发
基于产品思想的RA系统高效定制开发
摘要：本文针对目前RA（注册机构）系统设计中，用户需求不确定、系统设计困难的问题，按照基于产品，完成项目定制开发的思想，从尽量有效集成众多开源软件、并适当开发新技术的角度，本文提出了整套设计方案，有效满足了RA系统的设计要求，保证了RA系统的按时、按质完成。
关键字：RA（注册机构） 基于产品 项目定制 开源框架
Abstracts: This paper brings forward full solving blue print, which aiming at the problem of the faintness of users’ requirements and the trouble of system design, and according to the idea of accomplishing project customizing based on products, and from the point of view of integrating many open sources as much as possible and properly developing new technology. It in effect satisfies the RA design requirement and ensures the complete of RA system on time and on quality.
Keywords: RA (Registration Authority), Product-based, Project Customizing, Open Source
1 前言
1.1 PKI简介
PKI（Public Key Infrastructure），即公钥基础设施。它是利用公钥理论和技术建立的提供信息安全服务的基础设施，是国际公认的互联网电子商务的安全认证机制。它利用现代密码学中的公钥密码技术，在开放的Internet网络环境中提供数据加密，以及数字签名等服务的统一的技术框架。利用PKI可以方便地建立和维护一个可信的网络计算环境，从而使得人们在这个无法直接相互面对的环境中，能够确认彼此的身份和所交换的信息。
1.2 PKI组成
典型的PKI系统主要由四个部分组成：认证机构（CA）、注册机构（RA）、密钥管理中心（KMC）和证书库。
PKI各部分功能简述如下表所示：
PKI组成 |
功 能 |
|
认证机构（CA） |
证书机构CA是PKI的信任基础，它管理公钥的整个生命周期，其作用包括：规定证书策略、签发证书和发布证书废除列表（CRL）。 |
|
注册机构（RA） |
提供用户和CA之间的一个接口，负责收集提供用于证书的密钥对的生成和存储等功能用户信息，确认用户身份，然后向CA提出证书请求。 |
|
密钥管理中心（KMC） |
提供用于证书的密钥对的生成和存储等功能。 |
|
证书库 |
证书库用来存放经CA签发的证书和证书注销列表 (CRL)。 |
表1 PKI组成
2 当前PKI系统面临的设计问题及其解决方案
2.1 当前PKI系统设计面临的主要问题
在PKI的各个组成部分中，与PKI用户联系最紧密的是RA（注册机构）。RA作为用户与CA之间的一个接口，是用户经常面对和使用的PKI部分，因此，在设计上面临的问题也最多。
为了安全性考虑，尽力适应和满足用户不定的项目需求，同时，尽可能的实现RA功能的重用，对RA系统的设计提出了非常高的要求：
（1） 具有良好的安全性、可扩展性、可定制性和美观性。
（2） 尽力支持多操作系统平台和多数据库环境。
（3） 另外，由于RA系统本身要与多个系统，如CA、PMS（Privilege Management System）、数据库等系统交互，要求系统对其他系统有良好的可接入性。
（4） 由于要与多个系统进行交互，导致了系统的测试复杂，一旦测试完成，这时如果对系统作了新的修改，那么重复测试。如果系统设计不完善，那么新的修改又可能导致新的问题。为此，就要求RA系统的各个功能组件尽可能封装，并在各个RA系统之间尽可能复用，尽力避免重复测试和新的修改带来新的问题。
（5） 由于整套CA系统（包括RA）本身的重要性和高的市场准入门槛，导致系统价格高昂，为了尽可能降低用户购买负担，同时也为了尽可能提升项目的利润空间，就要求尽可能降低系统研发成本。
（6） 由于RA系统业务的特殊性，即一张数字证书从注册申请开始，到审核、签发、使用、过期或者冻结，到最终废除，在这期间，证书会有多种状态，那么，如何在用户的RA业务流程，即证书状态转换不确定的情况下，完成系统的设计和证书的状态转换？这就要求RA系统的业务逻辑层具有良好的灵活性。
2.2 解决方案
2.2.1 方案设计出发点
基于产品进行开发，即将RA的所有标准功能做成一个RA标准产品，然后按照项目需求，对RA标准产品进行必要的修改配置，并且在尽可能不修改源代码的情况下，就可实现项目需求。
2.2.2 方案设计要点
l 页面显示层：Common-controls开源框架和Apache的Tiles开源框架，完成页面显示；
l 控制流转层：Struts开源框架，灵活地定义了请求和响应的转发流程，以及灵活的数据校验功能；
l 证书状态操作：基于FSM（Finite Status Machine，有限状态机），所有状态定义，操作的前、后置条件，以及操作定义均在通过XML配置文件实现；
l 业务逻辑层：Commons-chains开源框架，实现了责任链模式，它将许多关联的原子操作按前后顺序关联在一起，然后顺序调用执行。基于此框架，可以灵活地增加新的原子操作，或者修改原子操作的前后顺序，从而实现新的功能；
l 数据持久层：BEA的dbKona开源框架，dbKona框架对常用的数据库操作作了良好的封装；
l 应用服务器：Tomcat等开源或非开源轻型应用服务器，提供应用服务。
2.2.3 方案设计思想
1、 本方案尽量基于已有的、经过不断测试的开源Java框架，以尽量降低开发量，减少bug。
2、 系统架构设计的目标之一就是：尽量在不重新修改和编译源代码、只需修改配置的情况下，就可实现所需要的功能。基于此，在本系统设计方案中，多处采用了容器的设计思路，如：页面表单的参数提交后都被收集到了类的Map类型属性中；往数据库插入数据，采用的是容器映射容器的设计思路，即：业务逻辑中的容器类对象映射数据库的表纪录对象。这样页面中增加了新的输入参数，中间层就不需重新修改和编译相关类，只需在数据库中增加相应字段，就可实现业务功能，从而有效降低了系统的重复测试和避免产生新的问题。
3、 尽量使系统轻型化，具有良好的应用服务器移植性和数据库移植性。使用了EJB的J2EE技术虽然技术先进，但技术复杂，开发维护成本高，另外还需要特定厂商的EJB服务器支持，因此，本方案没有采用EJB技术。
2.2.4 方案采用技术
一、使用面向容器编程
本方案在设计中，为了考虑可扩展性，尽量不重新编译源代码的情况下，就可增加新的功能，为此，本系统大量使用了容器的概念。如：
（1） 页面提交的请求数据都被存储到了Map类型的容器对象中。这样，如果在页面的表单中增加或减少了输入域，存储请求参数的ActionForm对象就不用修改，并重新编译。
（2） 一般情况下，在对数据库的操作中，如果数据库的表结构发生了改变，如增加了字段，那么相关的数据库操作代码也要相应修改。在这种情况下，又要重新编译源代码，并重复测试这些代码。对于简单的系统来说，可能不是问题，但对于复杂的系统，有可能会引起新的问题。在本系统的设计思路中，为了解决种问题，采用了容器映射的思想，即Map类型的容器对象映射数据库中的表对象。由于Map类型的容器对象是动态的，数据库中的表对象也是动态的，即可以根据需要修改表结构，这样，在dbKona框架的协助下，就可实现Map类型的容器对象的属性与数据库中的表对象的字段之间的一一映射，完全不会涉及到源代码的重新编译，从而较地解决了“仅仅是简单的修改就需要修改和重新编译源代码、并可能引起新的bug”的问题。
二、使用对显示效果和功能同时作了良好封装的Common-controls
为了页面显示效果的美化，在本系统中，采用了扩展自Struts框架Common-controls框架。这个框架对一些常用的页面显示组件作了良好的封装。只需按照常用的JSP标签使用这些Common-controls页面标签，不仅可以实现相应的功能，还可以达到良好的显示效果。另外，这些标签的使用，也不需要额外的代码，整个JSP页面非常简洁。如下例所示：
图2 Common-controls 的List标签示例
实现上面表单效果的源代码如下：
<ctrl:list
id="userlist1"
action="sample101/userBrowse"
name="users"
title="UserList"
width="500"
rows="10"
refreshButton="true"
createButton="true">
<ctrl:columndrilldown title="Id" property="userId" width="65"/>
<ctrl:columntext title="Name" property="name" width="350"/>
<ctrl:columntext title="Role" property="role.value" width="150"/>
<ctrl:columnedit title="Edit"/>
<ctrl:columndelete title="Delete" onclick="return userlist1_onBeforeServerSend();"/>
<ctrl:columnbutton title="Print" property="print" image="app/images/imgPDF.gif"
align="center"/>
</ctrl:list>
有限状态机（Finite State Machine）是一种应用非常广泛的软件设计模式（Design Pattern）。其作用主要是描述对象在它的生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。
在面向对象的软件系统中，一个对象经历的从开始创建到最终消亡的完整过程通常被称为对象的生命周期。一般说来，对象在其生命期内是不可能完全孤立的，它必须通过发送消息来影响其它对象，或者通过接受消息来改变自身。在大多数情况下，这些消息都只不过是些简单的、同步的方法调用而已。例如，在银行客户管理系统中，客户类（Customer）的实例在需要的时候，可能会调用帐户（Account）类中定义的getBalance()方法。在这种简单的情况下，类Customer并不需要一个有限状态机来描述自己的行为，主要原因在于它当前的行为并不依赖于过去的某个状态。
但是，在RA系统中的情况并不是如此简单，用户和用户对应的数字证书通常具有非常复杂的状态转换关系，而且需要对来自外部的各种事件进行响应。例如，一张用户的数字证书在不同的状态条件下，就会有不同的可进行的操作：刚注册申请完成的证书可以进行审核和修改操作，而已签发的证书则可以进行延期、废除和重新申请等操作。在这种情况下，使用状态机就是一个非常不错的选择。
但是，与其他常用的设计模式有所不同，程序员想要在自己的软件系统中加入状态机时，必须再额外编写一部分用于逻辑控制的代码，如果系统足够复杂的话，这部分代码实现和维护起来还是相当困难的。使用switch语句实现的有限状态机的确能够很好地工作，但代码的可读性并不十分理想，主要原因是在实现状态之间的转换时，检查转换条件和进行状态转换都是混杂在当前状态中来完成的。最令人头痛的是如果状态机中的状态非常多，或者状态之间的转换关系异常复杂，那么简单地使用switch语句构造出来的状态机将是不可维护的。
为此，本文从面向对象的角度，采用在配置文件中动态配置的方式，将状态机的长处有效应用到了本系统中，完美地解决了RA系统中用户和证书状态定义和转换的问题。
下面以一个简单的RA的状态机为例，说明在本系统中如何应用状态机。
状态机定义如下：
|
冻结用户 |
|
正常 |
|
已冻结 |
|
已注销 |
|
开始 |
|
用户注册 |
|
解冻用户 |
状态机说明：用户注册后，状态变为“正常”；对正常状态下的用户可以进行“冻结”和“注销”操作，用户自己则可以进行搜索、修改用户信息；对已冻结的用户可以进行解冻操作，使起变为“正常”状态；对已注销的用户，则不能进行任何操作。另外，对于已冻结和注销的用户，不能进行任何操作。
那么，为了实现上述状态机的功能，可以用下面的状态机配置文件：
<?xml version="1.0" encoding="GB2312"?>
<fsms defaultFsm="user">
<fsm name="user" desc="用户状态机">
<!--动作定义-->
<activities>
<activity name="about" desc="关于" command="/about" action="" />
<activity name="search" desc="搜索" command="/search" action="" />
<activity name="register" desc="注册" command="/ register " action="" />
<activity name="modify" desc="修改" command="/modify"
action="modify.do?value(USER_ID)={USER_ID}" />
</activities>
<!--状态定义-->
<statuses>
<status id="0" name="normal" desc="正常"/>
<status id="1" name="freezed" desc="已冻结"/>
<status id="-1" name="revoked" desc="已废除"/>
</statuses>
<!--状态转换定义-->
<transitions>
<transition name="about" desc="关于" activity="about"
initStatus="*" finalStatus="*"/>
<transition name="search" desc="搜索" activity="search"
initStatus="normal" finalStatus="normal"/>
<transition name="register" desc="注册" activity="register"
initStatus="*" finalStatus="normal"/>
<transition name="freeze" desc="冻结" activity="freeze"
initStatus="normal" finalStatus=" freezed "/>
<transition name="modify" desc="修改" activity="modify"
initStatus="normal" finalStatus="normal"/>
</transitions>
</fsm>
</fsms>
3 解决方案在RA项目中的应用
本文将以满足一个通用RA系统项目的普遍需求为建设目标，按照工程化的方法，详述上述解决方案的具体应用。
3.1 项目概述
l 项目名称：基于产品思想的RA系统高效定制开发
l 业务背景：PKI业务本身的复杂性，用户对PKI业务缺乏了解，需求定义不清晰、明确，对证书状态及其各个操作和操作流程需求模糊，造成RA系统的设计经常修改，进而时常影响项目进展。本文就是针对这一背景提出的，遵循本系统的设计思路，可以有效提高系统设计效率，降低项目风险。
l 可行性分析：PKI是一种遵循标准并利用公钥技术、为电子商务应用的开展提供一整套安全基础平台的技术与规范，它能够透明地提供基于公钥的加密和数字签名等安全服务；众多开源框架一般都经过反复的测试，应用在实际系统中，可有效降低系统的bug；另外，基于XML配置文件的证书状态机解决方案则有效解决了与证书状态有关的操作。
3.2 系统运行与开发环境
3.2.1 运行环境
1、硬件环境：
服务器端：PC Server，P4
2、软件环境
1）服务器端：
l 操作系统：Linux/Unix/Windows
l 应用服务器：Tomcat 5.5/WebSphere/WebLogic/JBoss
l 数据库服务器：Oracle8i/9i/，Sybase，MS SQL Server 2000
2）用户端：
操作系统：Windows 98/2000/XP/2003
浏览器：Microsoft IE 6.0
3.3.2 开发环境
1、硬件环境
1）服务器端：P4
2）客户端：P4
2、软件环境
l 操作系统：Windows XP Professional（SP1）
l IDE设计工具：Eclipse
l 数据库：Oracle8i/9i/，Sybase，MS SQL Server 2000
l 应用服务器：Tomcat 5.5
3.2 系统功能简介
3.1.1 范围
本PKI系统的RA子系统暂不提供与证书有关的功能，如签发、废除等功能，只提供与用户信息有关的管理功能，如注册、查询、修改和注销等。
3.1.2 功能描述
本系统共为四个模块，如下表所示：
|
模块名称 |
模块功能 |
|
用户管理模块 |
包括注册用户、查看用户信息、修改用户信息、冻结用户、解冻用户和注销用户 |
|
机构树管理模块 |
包括机构树的察看、机构的添加、修改和删除 |
|
系统配置管理模块 |
包括数据库连接参数配置、日志参数配置、查看系统运行日志 |
|
管理员管理模块 |
包括查询管理员、注册管理员和注销管理员 |
表4 系统功能模块
各个模块的用例图如下：
1、用户管理模块
图5 用户注册模块用例图
2、机构树管理模块：
图6 机构树管理模块用例图
3、系统配置管理模块
图7 系统配置管理模块用例图
4、管理员管理模块
图8 管理员管理模块用例图
3.1.3 用户状态机
在一个RA系统的设计中，最重要的一个部分就是设计用户和证书的状态及其转换，因为RA系统中所有与用户有关的操作都是针对用户本身和用户持有的证书。在操作过程中，都涉及到用户状态和证书状态的判断和转换。因此，必须保证用户状态和证书状态的正确定义，才能保证RA系统的设计正确，从而满足客户的需要。
针对本RA系统，与用户管理有关的状态机定义如下图所示：
|
开始 |
|
正常 |
|
[审核拒绝] |
|
注册待审核 |
|
注册审核未通过 |
|
[审核通过] |
|
[注册] |
|
[冻结] |
|
已冻结 |
|
[解冻] |
|
[注销] |
|
结束 |
|
更新待审核 |
|
[审核通过] |
|
[更新注册信息] |
|
更新审核未通过 |
|
[更新审核拒绝] |
图9 用户管理状态机
从以上状态机的状态图中，可以看出：一个用户从注册开始到注销有六种状态：注册待审核、注册审核未通过、正常、已冻结、更新待审核、更新审核未通过。要对用户进行某项操作必须满足用户当前的状态条件，如：要更新用户的注册信息，必须是在注册审核未通过或修改审核未通过的状态下，如果用户当前处于“正常”状态或“冻结”状态，则不能更新用户信息。同样，如果用户当前处于“冻结”状态，则不能注销用户。
3.3 系统框架
其他系统
RA
Commons-
chains
Commons-chains
Browser（JSP）
FronController
Struts-config.xml
WebAction
BackController
BizAction
CA
PMS
DBMS
Map Backed ActionForm
biz-config.xml
BizAction
BizAction
fsm-config.xml
3.3.1 系统框架图
|
其他系统 |
RA
|
|
Commons- chains Commons-chains |
|
Browser（JSP） |
|
FronController |
|
Struts-config.xml |
|
WebAction |
|
BackController |
|
BizAction |
|
CA |
|
PMS |
|
DBMS |
|
Map Backed ActionForm |
|
biz-config.xml |
|
BizAction |
|
BizAction |
|
fsm-config.xml |
图10 RA系统架构图
3.3.2 系统相关组件功能
按系统执行流程，相关组件的功能如下表所示：
|
Browser（JSP） |
完成前端页面显示，如收集用户请求信息，反馈系统相应结果 |
|
Map-backed ActionForm |
收集和存储用户输入的数据，在请求之间传递数据 |
|
FrontController |
前端控制器，负责控制所有的页面请求和页面响应 |
|
Struts-config.xml |
Struts框架的配置文件，负责配置页面请求对应动作的控制流转 |
|
WebAction |
控制器功能，获得FSM状态机配置和业务逻辑配置等功能 |
|
fsm-config.xml |
FSM（有限状态机）的配置文件，其中定义了用户和证书的所有状态及其转换配置 |
|
BackController |
后端控制器，在Commons-chains框架的帮助的下，完成业务逻辑的链式顺序执行 |
|
biz-config.xml |
业务逻辑流程的配置文件，定义了各个操作包含的所有原子操作 |
|
BizAction |
各个原子操作对应的执行单元 |
|
CA、PMS、DBMS |
与RA交互的其他系统 |
表11 系统相关组件功能
3.3.3 系统执行流程
以用户注册为例，系统执行流程如下：
1、 用户在注册页面中输入注册信息，提交注册请求。
2、 FrontController前端控制器将注册信息收集到Map-backed ActionForm中，然后调用请求对应的WebAction。
3、 WebAction从fsm-config.xml状态机配置中获得请求对应的具体执行动作，从biz-config.xml取得执行动作对应的业务逻辑配置，并调用BackController执行业务逻辑。
4、 BackController在Commons-chains框架的帮助的下，链式顺序地执行业务逻辑，即各个BizAction。
5、 各个BizAction完成具体的业务逻辑处理，如：1）与PMS交互，完成权限校验；2）与DBMS交互，实现数据库操作；3）与CA交互，获得经过CA签名的数字证书。
6、 业务逻辑处理完毕，返回结果给前台显示页面。
4 名词解释
l PKI（Public Key Infrastructure，公钥基础设施）：利用公钥理论和技术建立的提供信息安全服务的基础设施；
l CA（Certificate Authority，证书机构）：主要负责签发证书
l RA（Registration Authority，注册机构）：负责完成与用户和证书有关的操作，如：注册用户、签发证书、废除证书等
l PMS（Privilege Management System，权限管理系统）：负责权限校验
l FSM（Finite Status Machine，有限状态机）：有限状态机是一种用来进行对象行为建模的工具，其作用主要是描述对象在它的生命周期内所经历的状态序列，以及如何响应来自外界的各种事件
l 责任链（Chains of Responsibility）：一种设计模式，使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
5 参考文献
（1）《公钥基础设施（PKI）：实现和管理电子安全》，（美）那什等著，张玉清等译，北京：清华大学出版社，2002。
（2）《电子政务总体设计与技术实现》，国家信息安全工程技术研究中心和国家信息安全基础设施研究中心，北京：电子工业出版社，2003。
（3）《计算机网络安全教程》，石志国等，北京：清华大学出版社，2004.2。
（4）《计算机游戏程序设计》，肖永亮、耿卫东、陈为，北京：电子工业出版社，2005.3。
（5）《Verilog HDL程序设计与应用》，王伟，北京：人民邮电出版社，2005.3。
（6）Microsoft Windows 2000 Server 白皮书，
（7）Tanenbaum AS.计算机网络，北京：清华大学出版社，2002。
（8）《网络信息安全》，肖军模等，北京：机械工业出版社，2003。
（9）《计算机网络技术基础》，袁津生等，北京：人民邮电出版社，2002。
（10）《网络安全与保密》，胡建伟，西安：西安电子科技大学出版社，2003。
（11）X.509 Style Guide，Peter Gutmann，pgut001@cs.auckland.ac.nz，October 2000。
（12）Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile，RFC：3280。
（13）HMAC: Keyed-Hashing for Message Authentication，RFC：2104。
（14）Internet X.509 Public Key Infrastructure PKIX Roadmap。
（15）The Simple Public-Key GSS-API Mechanism (SPKM)，RFC：2025。
（16）《中华人民共和国电子签名法》，
