利用BEA WebLogic 8.1的安全特性

2004年3月10日，

基于J2EE和WebLogic平台8.1的EMALL系统是美国国防部关于采购和协作的商务门户。其中，EMALL的核心组件之一就是基于WebLogic Platform 8.1的规则引擎。

基于J2EE和WebLogic平台 8.1的EMALL系统是美国国防部关于采购和协作的商务门户。其中，EMALL的核心组件之一就是基于WebLogic Platform 8.1的规则引擎。

EMALL集成了基于.NET和J2EE技术的各种Web应用程序，DOD职员能够通过这些应用程序提交和跟踪订单信息。规则引擎对这些订单进行有效性检查并向各个防务供应商提交申请。在符合严格的安全条件下，所有这些系统利用ebXML 2.0实现互操作。在以前的文章中（WLDJ，第3卷，第1期），我们讨论了关于EMALL的整个体系结构。在本文中，我们将描述如何借助于BEA Weblogic Platform的安全特性来实现安全解决方案。

EMALL的安全需求
我们将回顾并讨论一些重要的安全需求并分析该系统所必须缓解的威胁以及风险。EMALL所处理的都属于敏感信息。只有具备相应的安全权限并获得批准的员工才能执行诸如浏览各个供应商目录、阅读各个产品的技术说明规范、提交订单和追踪订单状态等任务。审计也是该系统的关键要求。

部分重要的安全威胁如下所列：

1. 中间人攻击：该EMALL系统不仅在地理上覆盖了很广的面积，而且还横跨多个网络，其中包括了一些公共网段。
2. 消息篡改：攻击者试图对消息的内容做出修改。
3. 假扮攻击：该EMALL系统包括了多个商业和政府实体。这样，攻击者就有可能通过假扮一个合法实体进行攻击。
4. 特洛伊木马：多个DOD雇员能够访问EMALL。存在这样一种威胁：其中的单个或者多个个体会危及系统的安全。
5. 子系统的安全漏洞：EMALL包括了多个子系统，其中一些位于DOD供应商的网络中。如果在这样的子系统中存在的安全漏洞将会影响到整个EMALL。

设计目标
为了缓解这些风险因素，我们确定了如下的设计目标：

数据加密
所有实体间的流量必须经过强加密手段进行加密。这样就防止了中间人攻击的发生。

双向身份验证
所有参与到EMLL系统中的实体都必须通过数字证书来证明自己身份的合法性。数据交换的双方必须实施双向证书确认防止发生假扮攻击。

控制EMALL内各个子系统的角色
每个子系统实体都向其他实体提供特定的服务，同时也从其他实体获得特定的服务。这样当面临某个子系统出现安全问题时，使风险最小化。

访问控制
每个子系统都应实现面向内部用户的基于角色的安全性。对于各个子系统，这些机制并不一定相同。当规则引擎收到来自外部子系统的请求时，同时也收到包括了用户ID信息的消息。如果请求是关于服务调用的，那么引擎将会向该子系统传递相应的信任凭证。

数字签名
所有的消息都将进行数字签名，以防止未授权修改的发生。

审计追踪
所有消息都将用来进行审计追踪，以期识别安全漏洞和增强审计。追踪可能包括如下信息：

• 消息的内容
• 消息的数字签名
• 时间戳
• 发出该消息的用户ID

接受方必须对每条消息进行确认。

BEA WebLogic平台组件
图1展示了Weblogic平台中与安全基础结构相关的各个部分。

HTTPS和SSL特性
BEA Weblogic Server支持与EMALL有关的某些SSL的重要方面。

强加密
BEA WebLogic Server支持1024位证书和128位数据加密。

支持非对称密钥加密:
WebLogic Server支持RSA算法，包括对数字签名的支持。

双向证书验证
如果本特性生效，那么在建立任何连接之前，无论是客户端还是BEA WebLogic Server端都必须出示自己的SSL证书。在建立连接之前，WebLogic Server首先进行如下检查：

• 该证书是由一个受信权威机构签发的。
• 证书中的IP地址/主机名与该客户端的IP地址相匹配 。

WebLogic Security Provider Framework
BEA WebLogic Server支持由J2EE所声明的包含诸如用户ID、角色、访问控制列表、审计、安全事件等的安全性。要实现这些特性，WebLogic Server囊括了一个安全框架，该框架能够通过安全提供方的模块进行扩展。WebLogic Server允许这些模块采用即装即用的实现方式。您可以在框架中插入自定义的模块。与EMALL相关的部分模块如下所列：

1. 身份验证提供者（authentication providers）：根据用户所提供的凭据对用户进行身份验证。这可以是用户ID/密码，也可以是基于证书的凭证。
2. WLSUser：“主体”（Principal）对象的接口，该对象存放描述用户的安全信息。
3. 身份声明提供者（Identity assertion providers）：能够使用安全令牌，如CSIv2、SAML、 Kerberos和Microsoft Passport。
4. 主题验证提供者（principal validation providers）：处理签名、加密和跨多个WebLogic Domain安全信息的验证。它防止了对Weblogic Server间RMI调用的安全信息进行恶意篡改。
5. 授权提供者（authorization providers）：对BEA WebLogic Server内所有资源实施基于角色、用户ID和组等的安全策略。
6. 角色映射提供者（role-mapping providers）：允许动态角色关联。
7. 审核提供者（auditing providers）：追踪诸如访问特定资源的安全事件。它能够记录包括用户ID、时间戳、提供的凭据和对资源的访问等信息。该信息可以存储在数据库或者文件中。它也可以根据安全事件触发诸如通知相关安全人员等特定行为。

我们所设计的体系结构包括自定义的安全提供者模块来实现关于EMALL如下特性。

1. 通过为WLSUser创建一个自定义实现类来传递包括用户等级、安全-清除等级、数字签名和部门等的信息。
2. 开发一个自定义身份验证提供者，它将与一个核心安全数据库进行交互并对用户进行身份验证。接着提取所有必要的信息来完成实例化该WLSUser类的工作。
3. 开发一个自定义的身份声明提供者（identity-assertion provider）来实现单点登录（single sign-on，SSO）。
4. 开发一个自定义身份验证提供者（authorization provider）和自定义角色映射提供者（role-mapping provider）来对安全信息实施访问控制。本实现将会用到存储在自定义WLSUser实现中的信息，比如等级、清除级别等。
5. 实现一个自定义审计提供者（audit provider）来记录行为。存储在自定义WLSUser对象中的信息将被用来审计追踪。

部署在BEA Weblogic平台上的规则引擎和其他所有J2EE应用程序都将使用该框架。

到目前为止，我们已经讨论了有关核心BEA WebLogic Server的安全特性。接下来，我们将讨论由Weblogic Integration提供的B2B安全特性。

使用J2EE声明的安全约束
“规则引擎”应用程序包括了若干资源，比如需要由该安全框架提供保护的Web应用中的URL和EJB方法。出于这个目的，我们将使用web.xml和ejb-jar.xml文件中定义的J2EE安全约束。

交易伙伴配置
BEA WebLogic Integration允许我们通过配置交易伙伴来管理与其他业务实体的关系。在EMALL安全体系结构中使用的某些重要特性包括：

1. 将交易伙伴与数字证书相关联。这些证书将用于ebXML消息的加密和签名。
2. 定义由本地和远程交易伙伴提供的服务。
3. 定义与每个服务概要文件绑定的协议。这将包括业务协议ebXML 1.0、ebXML 2.0或RossettaNet和Transport Protocol（HTTP 1.0、HTTP 1.1或HTTPS 1.1）。
4. 为每一个“会话”或服务调用指定角色。
5. 用于管理交易伙伴配置的易用的、集中的管理控制台界面。

通过这些特色，我们就能够从“规则引擎”应用程序对所有参与到EMALL中的厂家进行交易伙伴配置的管理。

实现要点

在进行规则引擎的实现时，我们需要注意如下若干要点。

该ebXML参与进程（acceptCart.jpd）收到“Shopping Cart”文档，该文档除了包括用户元数据还有其他参数。在JPD文件中的代码将从该XML有效载荷中抽取这些信息并调用一个特定的无状态EJB。

该BEA WebLogic Server Security框架将会调用身份验证提供者（authentication provider），而它将实例化一个实现了weblogic.security.spi.WLSUser接口的自定义对象。而在具体实现该对象的类时，也可以通过附加的域来保存自定义的诸如等级、数字签名等安全数据。

通过无状态EJB的方法，我们可以获得相应的安全上下文和JAAS 主体。该对象实际上是由我们的身份验证提供者（authentication providervider）创建的WLSUser的自定义实现。这个对象是由其最初的类型强制转换而来的，所以植入了包含额外的自定义数据的域。

当该JPD代码调用规则引擎中的其它功能时，角色映射提供者（role-mapping provider）、授权提供者（authorization provider）等就会检查这些数据域

当访问受保护的资源时，WebLogic Security Framework就会调用自定义的审计提供者（audit provider）。这个审计提供者（audit provider）就会从这些数据域中抽取相关信息并将其记录到审计资料库中。

不可否认性
下面的体系结构特点为EMALL提供了对不可否认性的支持：

1. 广泛的审计追踪：该自定义审计提供者（audit provider）在审计追踪中记录了包括用户元数据、数字签名、时间戳等关键信息。
2. ebXML支持数字签名：只有拥有与该数字证书相对应的私钥的实体才能签发消息。该签名可以作为充分的证据来证明该消息是由正确的实体发出的。另外，一旦接收方收到该消息就通过ebXML进行确认，这也可以作为接收方实体已经接收该消息的证据。这两部分（消息签名和确认）一起可以作为当事人双方进行交易的证据。

结束语
EMALL系统对安全有着非常高的要求。借助于BEA WebLogic 平台 8.1所提供的安全特性，我们能够开发出满足这些要求的体系结构框架。该WebLogic Security Provider Framework对SSL的支持以及采用ebXML都成为了我们安全体系结构中最重要的因素。

致谢
作者非常感谢Bill Freeman博士，作为Integrated Solutions Group of the South Carolina research Authority研究和开发主管，他提供了很多支持。Freeman博士也是来自SCRA的DOD EMALL项目经理。BEA公司和ICF向SCRA提供了所需的工程服务。同时我们也向来自BEA工程团队的Ricardo Valenzuela、Madhavan Rangarao、Dmitry Dimov和Komal Mangtani致谢，他们为我们实现预定目标提供了技术上的支持。