【IT168 技术文章】

    本文是探索真实用例场景的系列文章的第二部分，介绍与基于证书的 XML 标准加密相关的安全问题。详细阐述 XML 标准和 WS-Encryption 规范。提供的分步说明向您介绍了如何配置 IBM® WebSphere® DataPower® SOA Appliances 及其扩展功能以提升公钥基础结构 (PKI)，从而保护 XML 文档各部分中包含的敏感数据在传输中的私密性。您应基本了解 XML 以及与安全相关的概念才能按照本文的叙述进行操作。

    引言 

    本系列的第 1 部分介绍了卫生保健预约系统并描述了贯穿本系列的一个要实现的场景。图 1 列出了本系列所基于的完整结构图。

图 1. 预约系统
 

    在此场景中，您将了解远程诊所如何向中央系统完全地委托预约服务，该中央系统填写它们的预约时段并以 SOAP 消息的形式定期发回更新的日程。每个消息在其正文中都包括一个 serviceProviderId，它唯一地标识必须将此消息发送到的诊所。本文重点介绍 WebSphere DataPower SOA Appliances 并分析它在提升 PKI 中所扮演的角色。

    我们首先分解该流程并对其进行总体概述。在获得针对特定诊所的 SOAP 消息时，WebSphere DataPower SOA Appliances 将：

    1.解析该消息。
    2.获取 serviceProviderId。
    3.根据检索的 serviceProviderId 动态选择服务提供者的证书，并使用此证书加密消息。
    4.使用指定的端点绑定将结果 SOAP 消息发送到企业服务总线 (ESB)。

    以下各部分介绍了执行如下操作的详细步骤：

    *加密 SOAP 信封。
    *为测试目的生成密钥证书对并上传到 WebSphere DataPower SOA Appliances。
    *将 WebSphere DataPower SOA Appliances 配置为 Web 服务代理，并将加密的消息转发到 ESB。
    *在运行时使用 WebSphere DataPower SOA Appliances 的一些扩展功能动态选择此证书，并使用此证书执行加密。

    寻找用于加密机密数据的方法

    通常，在需要发送一些敏感数据时，可以通过两种方法来保护通信。一种是使用安全套接字层 (SSL)，它可以保护整个通信的安全。但是，仅基于 HTTP 的安全是不够的。HTTP 及其安全机制仅能解决点到点的安全问题。当消息可能跨多个跃点传递时，您必须使用更复杂的解决方案，该解决方案应能够在多点消息路径中保持一个安全上下文。共有两种可能的方法可以帮助解决此问题：

    *WS-Security
    *XML 标准加密

    这两个解决方案都提供了消息级别的安全性，将安全功能合并到 SOAP 消息中并作用于应用层，因此保证了端到端的安全。WS-Security 加密方法是加密 SOAP 消息的 Web 服务安全标准，而 XML 加密方法是可用于加密 XML 消息甚至其一部分的标准。为更好地理解这两种加密之间的不同，我们根据将要解决的场景比较一下这两种方法。

    假定通过中央预约系统传输的日程包含了关于预约时段的日期的所有信息，这些信息包装在 sdoWrapper 服务数据对象 (xmlString) 中，并用类似于 XML 的格式表示，如清单 1 所示。

清单 1. SOAP 消息
               
<soapenv:Envelope
xmlns:soapenv="http://schemas.XMLsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header />
<soapenv:Body>
<p374:sendUpdatedAgenda xmlns:p374="http://Asynch_Library/AsynchResSystemExport">
<sdoWrapper>
<xmlString />someConfidentialContent </xmlString >
<sdoWrapper/>
<serviceProviderId >ASL1<serviceProviderId >
</p374:sendUpdatedAgenda >
</soapenv:Body>
</soapenv:Envelope>

    由于此消息是机密消息，因此需要一些信息才能确定要将消息发送到的服务提供者；已经为此目的添加了 serviceProviderId。为保护此数据，我们决定加密整个 sdoWrapper 服务数据对象。如果需要向 sdoWrapper 对象添加更多的敏感信息，此选项可以保证提供较好的灵活性。不过，请记住，使用 XPath 表达式还可以仅加密 XML 消息的服务数据对象的某一部分。

    XML 标准加密和 WS-Encryption 都遵循两步加密数据的方法：

    1.使用受信方证书中包含的公钥生成共享密钥（非对称加密）。
    2.使用以前生成的密钥加密 SOAP 消息中的敏感数据（对称加密）。

    这样，您使用非对称加密仅生成和保护了要共享的密钥，而使用对称加密来执行数据加密，因此提高了性能。当收到加密的消息时，受信任方使用其私钥解密会话密钥，然后使用它解密消息。此机制确保了只有受信方可以执行消息的解密，而此受信方只能是拥有正确私钥的一方。在清单 2 中，您可以看到将 WS-Encryption 应用于上文描述的 SOAP 消息以加密服务数据对象的结果。

清单 2. WS-Encryption
               
    <?xml version="1.0" encoding="UTF-8" ?>
-<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:soapenv="http://schemas.XMLsoap.org/soap/envelope/"

  -<soapenv:Header> 
   -<wsse:Security soapenv:mustUnderstand="1"                                       
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/                                
    oasis-200401-wss-wssecuritt-secext-1.0.xsd">                                    

    <xenc:EncryptedKey xmls:xenc="http://www.w3.org/2001/04/xmlenc#">            
     <xenc:EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"      
     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">                                
     -<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      -<wsse:SecurityTokenReference>|
       <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis
         -2004-wss-x509-token-profile-1.0#x509v3SubjectKeyIdentifier"EncodingType=
         "http://docs.oasis-open.org/wss/2004/01/oasis-2004-wss-soa-message-security
          -1.0#Base64Binary">EOStvn5dTJTROjuM2rn9Ov9dQlQ=
        </wsse:KeyIdentifier>
        </dsig:KeyInfo>
       -<xenc:ChiperData xmls:dsig="http://www.w3.org/2000/00/xmldsigc#">
       <xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
       czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
       jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
      </xenc:ChiperData>
     </xenc:EncryptedKey>

   </wsse:Security>
  </soapenv:Header>

  -<soapenv:Body>
   -<q0:sendUpdatedAgenda >
     -<xenc:EncryptedData Id="G248054f8-1bD" Type="http://www.w3.org/2001/04
      /xmlenc#Element"xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
      xmlenc#tripledes-cbc"/>
    -<xenc:ChiperData >
      <xenc:ChiperValue >DDY/AI0WDQppKgcyc09cBkwjXNPQ8NleT5234ZMvudcLqQJ4
      cDFGTh67+sTr23KYXAsw0M+kc2opDsErt543lkvuHTP+lllCV=OPPmhjkoikZMvudcLqQJ4
      ZUijE1111+XsvvBz3wh34hedcls2FTss$+sTr23KYXAsw0M+kzPSRt4ZMvud+sTr23KYXAs
      jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
     </xenc:ChiperData>
    </xenc:EncryptedData>
   <serviceProviderId >ASL1<serviceProviderId >
  </q0:sendUpdatedAgenda >
 </soapenv:Body>

</soapenv:Envelope>
     

    注意，通过使用 WS-Encryption，与生成的共享密钥相关的所有信息都包含在消息头中，而加密的数据则包含在消息正文中。对于生成的密钥而言，此结构的根元素是 EncryptedKey，它包含 dsig:KeyInfo 和 dsig:KeyValue 元素，二者都属于同一 XML 数字签名 (dsig:) 命名空间。而加密的数据则包含在 EncryptedData 元素中，该元素属于 XML 加密 (xenc:) 命名空间。EncryptedKey 和 EncryptedData 部分分别包含有关用于非对称加密密钥 (rsa_15) 和对称加密数据 (tripledes-cbc) 的算法的详细信息。CipherValue 元素则包含密钥和敏感数据的加密值。使用标准 XML 加密方法来加密 sdoWrapper 服务数据对象将生成如清单 3 所示的结果。

清单 3. 标准加密
               
 <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soapenv="http://schemas.XMLsoap.org/soap/envelope/"
 xmlns:q0="http://Asynch_Library/AsynchResSystemExport">

  -<soapenv:Body>
   -<q0:sendUpdatedAgenda >
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#triplesdes-cbc"/>
     -<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
       <xenc:EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"
        -<xenc:ChiperData>
         <xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
         czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
         jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
         </xenc:ChiperData>
         </xenc:EncryptedKey >
      </dsig:KeyInfo >
     -<xenc:ChiperData xmls:dsig="http://www.w3.org/2000/00/xmldsigc#">
      <xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
      czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
       jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
      </xenc:ChiperData>
      </xenc:EncryptedData>

  <serviceProviderId >ASL1<serviceProviderId >
 </q0:sendUpdatedAgenda >
</soapenv:Body>
</soapenv:Envelope>
      
    这里需要重点强调的一点是，这与直接使用 WS-Encryption 加密方法不同。通过使用标准 XML 加密，所有与安全相关的信息，包括加密密钥和加密的数据都包含在 SOAP 消息的正文中（加密的密钥不再嵌入 SOAP 头中）。而且，对于以类似于 XML 格式编写的 SOAP 消息，您始终可以使用 XML 标准加密方法来加密 SOAP 消息的正文或正文的某部分。当您需要在 SOAP 消息的正文中传输与安全相关的所有信息（如用于执行加密的算法、加密的共享密钥、加密的数据等）时，此方法特别有用。

    在本例中，SOAP 消息（如上所述）在被加密后转到执行协议切换的 ESB，然后将这些消息路由到一些 Java™ Message Service (JMS) 客户端，所有客户端都在同一主题上注册。加密可以保证有关某个主题的数据机密性，原因是只有拥有正确私钥的服务提供者才能正确执行解密，因此也能读懂该数据。在此场景中，采用 WS-Encryption 方法加密数据显然不是一个好选择。事实上，对于 SOAP 消息头中提供的与密钥相关的信息，该信息将在消息转换为 JMS 格式时丢失。不过，使用标准 XML 加密，安全信息将不会丢失，这是因为嵌入消息的正文将意味着它将得到保留并只需转换为 JMS 负载。JMS 客户端然后将该消息转换为 XML 文本格式，并使用标准 API 对其解密。由于必须加密这些 SOAP 消息，我们决定利用 WebSphere DataPower SOA Appliances 的功能来执行标准 XML 加密，以避免在中央预约系统上加密和解密 SOAP 消息的编程负担。

    利用 WebSphere DataPower SOA Appliances 功能加密机密数据

    要对 XML 文档的内容进行签名，您需要一个私钥和一个公开证书。在大多数情况下，受信任的证书颁发机构将为您提供证书/密钥对。如果您希望为测试目的自己生成证书/密钥对，则可以执行以下操作之一：

    *直接使用 WebSphere DataPower SOA Appliances 的 Crypto Tools 生成证书/密钥对。
    *通过 Java 密钥工具生成证书/密钥对，然后将其上传到 WebSphere DataPower SOA Appliances。

    下一节将探讨这两种方法。如果已经具备要使用的私钥和公钥，请跳到将证书上传到 WebSphere DataPower SOA Appliances 设备部分。

    使用 WebSphere DataPower SOA Appliances 加密工具构建证书

    WebSphere DataPower SOA Appliances 提供了一些加密工具，通过这些工具可以生成自签名证书和私钥。稍后可以通过文件管理实用工具从 WebSphere DataPower SOA Appliances 下载这些工具。要创建证书，请执行下列操作：

    1.登录到 WebSphere DataPower SOA Appliances 设备。指向设备的 URL 通常为 https://servername:9090/，但是您可能需要向 WebSphere DataPower SOA Appliances 管理员验证该地址。
    2.分别输入用户 ID 和密码。
    3.选择域，然后单击 Login。
    4.在控制面板中，单击左侧导航窗格中的 Administration 选项卡。
    5.在 Administration 选项卡的底部，选择 Crypto Tools。
    6.在 Generate Key 区域中，填写 Common Name 和 Object Name 字段。对象名代表证书的别名，在每次使用证书（如执行加密）时必须提供此名称。
    7.确保 Password Alias 文本字段中的所有单选按钮都设置为 on。
    8.如图 2 所示，提供有关证书/密钥对的任何可选信息。

图 2. 使用 Crypto Tools 生成证书/密钥对
 

    9.单击 Generate Key。WebSphere DataPower SOA Appliances 将生成一个自签名证书和一个私钥，并将二者存储在临时文件夹中。稍后可以通过文件管理实用工具从 WebSphere DataPower SOA Appliances 下载它们。

    需要重点强调的是，生成的证书和私钥的格式都是 .pem，因此必须通过 Open-SSL 工具转换此格式才能将其导入到任意 Java 密钥存储库。

    使用 WebSphere DataPower SOA Appliances 加密工具上传现有证书

    如果希望仅使用 WebSphere DataPower SOA Appliances 加密数据并希望使用基于 Java 的应用程序执行解密（本系列文章中使用的就是这种方法），则最好使用密钥工具生成证书/私钥对，然后仅将证书上传到 WebSphere DataPower SOA Appliances。这样，解密应用程序就不需要转换证书和私钥。您可以将证书导入 WebSphere DataPower SOA Appliances 以供以后加密使用。

    回到本文提供的场景，假设每个服务提供者都有自己的证书，并将其证书发布到预约系统，该系统负责将证书上传到 WebSphere DataPower SOA Appliances。为简单起见，本示例使用了自签名证书，但在真正的环境中，每个服务提供者显然都应有证书颁发机构（如 VeriSign）颁发的证书。

    要生成自签名证书，只需将 Java Development Toolkit 安装在您的计算机上。这样您可以方便地切换到 java/bin 路径并运行 keytool 命令，提供有关每个服务提供者的必要信息，方法与清单 1 中为名为 ASL1 的通用卫生服务提供者提供的信息类似。

清单 4. 示例命令
               
keytool  -genkey -alias ASL1_cert -key alg RSA -validity 365 -keystore signer.jks
   -storepass signer -dname "CN=AS L1, OU=Development, O=Health Care,
    L=Rome, ST=N/A, C=IT" -keypass ASL1_key
 

    在本例中，ASL1_cert 是证书的别名；signer.jks 是创建的密钥存储库，它包含 RSA 密钥对；signer 是密钥存储库的密码；ASL1_Key 是为证书提供的通用密码。在完成上述步骤之后，可以导出别名 ASL1_cert 的公钥，这样即可在以后将其上传到 WebSphere DataPower SOA Appliances。

清单 5. 示例命令
               
keytool -export -alias ASL1_cert -keystore signer.jks
   -storepass signer -file ASL1.cert

    在本例中，您使用了八个服务提供者：从 ASL1 到 ASL8。您根据上述步骤为每个服务提供者生成了一个自签名证书并明确修改了要存储在证书中的别名和提供者的信息。然后，将这些证书上传到 WebSphere DataPower SOA Appliances。

    将证书上传到 WebSphere DataPower SOA Appliances 设备

    要将一些证书上传到 WebSphere DataPower SOA Appliances 设备，请执行下列步骤：

    1.登录到 WebSphere DataPower SOA Appliances 设备。在控制面板中，单击 Keys and Certs Management 图标。
    2.在打开的窗口中，选择 Certificates，然后单击 Add（请参见图 3）。

图 3. 密钥和证书管理

    3.在出现的下一个窗口中，单击 Upload。
    4.在您的计算机上浏览到证书所在的位置，然后按 OK（请参见图 4）。

图 4. 加密证书
 

    5.输入 ASL1_cert 作为证书名，在稍后的操作中该名称将用作证书对象的别名。

    将 WebSphere DataPower SOA Appliances 配置为 Web 服务代理

    现在可以检测 WebSphere DataPower SOA Appliances 以执行标准 XML 加密。在您的配置中，WebSphere DataPower SOA Appliances 充当 Web 服务代理，从中央系统获取 SOAP 消息，执行加密，然后将这些消息转发到 ESB。在本部分中，将分步介绍如何将 WebSphere DataPower SOA Appliances 配置为 Web 服务代理，以便执行下列操作：

    *在指定的统一资源标识符 (URI) 处侦听 SOAP 消息。
    *使用 Web 服务描述语言 (WSDL) 文件（部署在 ESB 计算机上）中指定的绑定信息将这些消息转发到 ESB。
    *应用加密策略对传入消息执行标准 XML 加密。

    让我们从头开始：

    1.在控制面板中，单击 New Web Service Proxy 图标。将显示 Web 服务代理配置页。
    2.在 Proxy Name 字段中输入 ESB_Proxy。
    3.单击 Upload 上传 WSDL（请参见图 5）。

图 5. Web 服务代理
 

    4.选择 Export1_AsynchResSystemExportHttp_Service.wsdl 作为要上传的文件，然后按 OK。

    注意：Export1_AsynchResSystemExportHttp_Service.wsdl 文件包含绑定信息并在 ESB 上生成。详细信息将在本系列的下一篇文章中提供。您可以下载一个示例（具有缺省配置）。要让 WebSphere DataPower SOA Appliances 正确解析     Export1_AsynchResSystemExportHttp_Service.wsdl 文件，还需要上传 xenc.xsd、xdig.xsd 和 AsynchResSystemExport.wsdl 文件。前两个文件包含 XML 加密和用于执行加密的 XML 数字签名命名空间，最后一个文件包含在 ESB 上部署的服务的接口定义，WebSphere DataPower SOA Appliances 在对敏感数据执行加密后必须调用此接口定义。为此，在创建 Web 服务代理之前，请使用文件管理实用工具将这些文件上传到本地文件夹。这可以保证在代理创建阶段上传 Export1_AsynchResSystemExportHttp_Service.wsdl 时，WebSphere DataPower SOA Appliances 能够成功解析此文件。
    5.在上传和成功解析此文件之后，您应看到一些新的文本字段，其中填充了上传的 WSDL 文件中包含的端点值。此信息根据要联系的 ESB 主机名、其端口地址和要调用服务的 URL 检测 WebSphere DataPower SOA Appliances。您应原样保留此数据（请参见图 6）。

图 6. WSDL 端点设置
 

    6.要作为代理使用，以便将消息转发到 ESB，WebSphere DataPower SOA Appliances 必须在指定的 URI 上侦听某个端口。要提供此信息，请单击 Local Endpoint Handler 下方的 + 号图标以显示一个下拉列表。
    7.选择 HTTP Front Side Handler，如图 7 所示。

图 7. 创建 HTTP 处理程序
 

    8.这将显示一个新窗口。输入 ESB_Handler 作为名称，并提供一个可用端口。
    9.单击 Apply。图 8 显示了结果。

图 8. 配置 HTTP 前端
 

    10.屏幕将刷新，您将在 Web Service Proxy 窗口中看到所提供信息的摘要。单击 Apply，然后单击 Save 按钮以保存执行的更改。
    11.单击 Web 服务代理上的 Policy 选项卡。
    12.选择 Request 规则，然后双击该规则。策略窗口将出现在页面的底部，如图 9 所示。

图 9. 配置策略
 

    13.单击 Encrypt 操作，并将其拖动到策略窗口上。
    14.双击 Encrypt 操作。在出现的窗口中，选择 Advanced 选项卡。
    15.要对 SOAP 消息正文（sdoWrapper 服务数据对象）的一部分执行标准 XML 加密，您需要选中 Standard XML Encryption 和 Selected Elements(Field-Level) 复选框。

图 10. 配置加密操作
 

图 11. 配置文档加密
 

    18.单击 Upload 从类文件文件夹中上传 soa_msg.xml 文件（如清单 1 所示）。
    19.单击 Compare Local Name Only 单选按钮。这将创建缩短的 XPath 表达式。
    20.在显示的模式文件中选择 sdoWrapper 字段。单击字段 Name（不是单击字段内容）。

图 12. 选择示例 XML 文档 
 

    21.单击 Done 接受显示的 XPath 表达式。这将关闭此窗口。
    22.单击 Add 将 XPath 表达式添加到此映射使用的表达式列表。请参见图 13 中的 Document Crypto Map。

图 13. Document Crypto Map
 

    23.单击 Apply 完成 Document Crypto Map 的配置。这将打开加密配置窗口（请参见图 14）。

图 14. 配置加密操作 
 

    24.在加密算法列表框中可以选择对称算法，使用该算法可以加密 SOAP 消息正文中包含的服务数据对象。您还会注意到位于页面中间的 Use Dynamically Configured Recipient Certificate 复选框。将它的值设置为 on 将导致此步骤中的加密使用动态配置的接收方证书。如果提供了动态配置的接收方证书（例如通过样式表提供，这将在下面的部分中描述），则该证书将优先于接收方证书中定义的证书。因此，您可以将此文本字段留空 (none) 并在以后运行时检查是否选择了有效的证书.

    配置样式表以便在运行时选择证书

    现在可以执行此场景中的最后一步了。每个 SOAP 消息都发往 SOAP 消息正文中包含的 serviceProviderId 字段标识的特定服务提供者。您已经将类型 serviceProviderId_cert 的命名约定标识的多个证书上传到了 WebSphere DataPower SOA Appliances，其中 serviceProviderId 可以是 ASL1 至 ASL8（8 是本例中服务提供者的数量）。对于每个传入的 SOAP 消息，WebSphere DataPower SOA Appliances 必须知道用来执行加密的证书。因此，现在您需要实现一个机制来解析 SOAP 消息的请求、获取 serviceProviderId 并用它来找到正确的证书。

    正如上一部分中所阐述，在加密页中启用 Use Dynamically Configured Recipient Certificate 选项会自动触发 WebSphere DataPower SOA Appliances 执行加密，并利用在运行时提供的证书：如果已经为上下文变量 var://context/transaction/dynamicCertName 指定了一个值，并且它引用了一个有效的证书，则在加密步骤中将使用此证书。否则，将使用接收方证书中指定的缺省值（如果已经提供）。图 15 对此进行了说明。

图 15. 加密规则
 

    要完成 WebSphere DataPower SOA Appliances 的配置，请执行下列步骤：

    1.如清单 4 所示创建样式表。

    清单 6. WebSphere DataPower SOA Appliances 命名空间和扩展元素前缀
                       
<xslt:stylesheet version="1.0"
extension-element-prefixes="dp"xmlns:tns="http://www.w3.org/1999/xhtml"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<dp:set-variable name="'var://context/transaction/dynamicCertName'"
value="concat('cert:', concat(/*[local-name()='Envelope']/*
[local-name()='Body']/*[local-name()='sendUpdatedAgenda']/*
[local-name()='serviceProviderId'],_cert))" />
</xsl:template >
</xsl:stylesheet>

    此样式表为各项功能和 dp 扩展元素前缀声明特定于 WebSphere DataPower SOA Appliances 的命名空间 (dp:)。在每次需要使用特定于 WebSphere DataPower SOA Appliances 的扩展功能时必须始终定义这些元素。在样式表中使用扩展功能时，它代表一个强大的方法，可以丰富、加密、集成和促进通过简单的 Web UI 提供的 WebSphere DataPower SOA Appliances 功能。在此场景中，您根据 SOAP 消息正文中包含的 serviceProviderId 字段中的值调用了 dp:set-variable 扩展功能来设置上下文变量 var://context/transaction/dynamicCertName。concat 功能是基本的 XSL 功能，它只需将 serviceProviderId 检索的值连接到 _cert 字符串就可以正确标识 WebSphere DataPower SOA Appliances 上的证书。

    2.将 XSL 转换添加到 Web 服务代理策略窗口。要执行此操作，请选择 Transform 选项，并在加密操作之前将其拖放到策略窗口。（请参见图 16）。

图 16. 添加 XSL 转换
 

    3.双击 Transform 图标。这将显示一个窗口。单击 Upload 按钮，浏览到 set_cert_name.xsl 文件所在的位置，单击 OK。
    4.从输出列表框中选择 none，以避免样式表改变数据的内容。在此场景中，样式表的实际目的只是设置一个变量，而不是转换消息的内容。如果选择 auto 或 pipe 作为输出类型，则 SOAP 消息将通过样式表转换，并且其输出将发送到加密操作（策略页中的下一操作），从而改变了消息的内容。在图 17 中可以看到其具体情况。

图 17. 配置转换操作
 

    5.在运行时验证是否正确设置了 var://context/transaction/dynamicCertName 变量。要执行此操作，可以在 WebSphere DataPower SOA Appliances 的 ESB_Proxy Web 服务代理上启用探测器，并在 XSL 转换之前和之后检查上下文变量的内容。这样，您应能够看到变量的设置在转换之后仍是正确的并且直到加密操作结束时它的值也保持不变。
 
    结束语

    您学习了如何使用 WebSphere DataPower SOA Appliances 来提升 PKI。还学习了如何动态选择服务提供者的证书、执行标准 XML 加密并将加密的 SOAP 消息转发到 ESB。本系列的后续文章将介绍如何检测 ESB 以接受这些消息，执行协议切换，然后将这些消息转发到注册服务提供者的 JMS 主题。请继续关注！