Apache CXF 安全指南

可用的商业 CA 有多种。使用商业 CA 签名证书的机制取决于您所选的 CA。

商业 CA 的一个优点是它们通常被大量人信任。如果您的应用程序被设计为可用于您的机构外部的系统，请使用商业 CA 为证书签名。如果您的应用程序在内部网络中使用，则可能适当地使用私有 CA。

在选择商业 CA 前，请考虑以下标准：

如果要负责为您的系统签名证书，请设置私有 CA。要设置私有 CA，您需要访问提供创建和签名证书的实用程序的软件包。这个类型的几个软件包可用。

一个允许您设置私有 CA 的软件包是 OpenSSL http://www.openssl.org。OpenSSL 软件包包括用于生成和签名证书的基本命令行工具。OpenSSL 命令行工具的完整文档位于 http://www.openssl.org/docs。

要设置私有 CA，请参阅 第 2.5 节 “创建您自己的证书” 中的说明。

选择主机是设置私有 CA 的一个重要步骤。与 CA 主机关联的安全级别决定了与 CA 签名的证书关联的信任级别。

如果您要设置用于在红帽 Fuse 应用程序的开发和测试中使用的 CA，请使用应用程序开发人员可访问的任何主机。但是，当您创建 CA 证书和私钥时，请不要在运行安全关键应用程序的任何主机上提供 CA 私钥。

如果您要设置 CA 为您要部署的应用程序签名证书，请尽可能使 CA 主机安全。例如，要采取以下措施来保护您的 CA：

本节中描述的步骤基于 OpenSSL 项目中的 OpenSSL 命令行工具。有关 OpenSSL 命令行工具的更多文档，请访问 http://www.openssl.org/docs/。

为了说明这一点，假设 CA 数据库具有以下目录结构：

其中 X509CA 是 CA 数据库的父目录。

这部分论述了如何设置自己的私有 CA。在为实际部署设置 CA 前，请阅读 第 2.2.3 节 “私有证书颁发机构” 中的附加备注。

要设置您自己的 CA，请执行以下步骤：

在安全 CA 主机上，将 OpenSSL bin 目录添加到您的路径中：

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

此步骤使 openssl 工具可用。

创建新目录 X509CA 以存放新 CA。此目录用于保存与 CA 关联的所有文件。在 X509CA 目录中，创建以下目录层次结构：

将示例 openssl.cnf 从您的 OpenSSL 安装复制到 X509CA 目录。

编辑 openssl.cnf，以反映 X509CA 目录的目录结构，并确定新 CA 使用的文件。

编辑 openssl.cnf 文件的 [CA_default] 部分，使其类似如下：

#############################################################
[ CA_default ]

dir        = X509CA            # Where CA files are kept
certs      = $dir/certs  # Where issued certs are kept
crl_dir    = $dir/crl          # Where the issued crl are kept
database   = $dir/index.txt    # Database index file
new_certs_dir = $dir/newcerts  # Default place for new certs

certificate   = $dir/ca/new_ca.pem # The CA certificate
serial        = $dir/serial        # The current serial number
crl           = $dir/crl.pem       # The current CRL
private_key   = $dir/ca/new_ca_pk.pem  # The private key
RANDFILE      = $dir/ca/.rand
# Private random number file

x509_extensions = usr_cert  # The extensions to add to the cert
...

您可以决定在此点编辑 OpenSSL 配置的其他详情，详情请参阅 http://www.openssl.org/docs/。

在 X509CA 目录中，初始化两个文件，即 serial 和 index.txt。

Windows

要在 Windows 中初始化 串行 文件，请输入以下命令：

> echo 01 > serial

要创建空文件 index.txt，在 Windows 中，在 X509CA 目录中的命令行中启动 Windows Notepad，如下所示：

> notepad index.txt

要响应带有文本的对话框，Cannot find the text.txt file。是否要创建新文件？，点 Yes 并关闭 Notepad。

UNIX

要在 UNIX 中初始化 串行 文件和 index.txt 文件，请输入以下命令：

% echo "01" > serial
% touch index.txt

CA 使用这些文件来维护其证书文件的数据库。

使用以下命令创建新的自签名 CA 证书和私钥：

openssl req -x509 -new -config X509CA/openssl.cnf -days 365 -out X509CA/ca/new_ca.pem -keyout X509CA/ca/new_ca_pk.pem

该命令提示您输入 CA 私钥和 CA 区分名称的密码短语。例如：

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
....++
.++
writing new private key to 'new_ca_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Finance
Common Name (eg, YOUR name) []:Gordon Brown
Email Address []:gbrown@redhat.com

您必须确保 CA 证书和私钥的文件名和位置 new_ca.pem 和 new_ca_pk.pem 与 openssl.cnf 中指定的值相同（请参阅前面的步骤）。

现在，您可以使用您的 CA 签署证书。

要在 Java 密钥存储(JKS)、CertName.jks 中创建并签署证书，请执行以下子步骤：

如果您还没有这样做，请将 Java bin 目录添加到您的路径中：

Windows

> set PATH=JAVA_HOME\bin;%PATH%

UNIX

% PATH=JAVA_HOME/bin:$PATH; export PATH

此步骤使 keytool 工具可从命令行使用。

打开命令提示符，并将目录更改为存储密钥存储文件的目录 KeystoreDir。输入以下命令：

keytool -genkey -dname "CN=Alice, OU=Engineering, O=Progress, ST=Co. Dublin, C=IE" -validity 365 -alias CertAlias -keypass CertPassword -keystore CertName.jks -storepass CertPassword

此 keytool 命令通过 -genkey 选项调用，生成 X.509 证书和匹配的私钥。证书和密钥都放置在新创建的密钥存储 CertName.jks 中的密钥 条目中。由于指定的密钥存储 CertName.jks 在发出命令之前不存在，keytool 会隐式创建新的密钥存储。

-dname 和 -validity 标志定义新创建的 X.509 证书的内容，分别指定主题 DN 和过期前的天数。有关 DN 格式的详情，请参考 附录 A, ASN.1 和可辨识名称。

主题 DN 的某些部分必须与 CA 证书中的值匹配（在 openssl.cnf 文件的 CA Policy 部分中指定）。默认 openssl.cnf 文件需要以下条目才能匹配：

为 CertName.jks 证书创建新证书签名请求(CSR)，如下所示：

keytool -certreq -alias CertAlias -file CertName_csr.pem -keypass CertPassword -keystore CertName.jks -storepass CertPassword

此命令将 CSR 导出至文件 CertName_csr.pem。

使用您的 CA 为 CSR 签名，如下所示：

openssl ca -config X509CA/openssl.cnf -days 365 -in CertName_csr.pem -out CertName.pem

要成功签署证书，您必须输入 CA 私钥密语（请参阅 第 2.5.2 节 “设置您自己的 CA”）。

将签名证书 CertName.pem 转换为 PEM 的唯一格式，如下所示：

openssl x509 -in CertName.pem -out CertName.pem -outform PEM

串联 CA 证书文件和 CertName.pem 证书文件，如下所示：

Windows

copy CertName.pem + X509CA\ca\new_ca.pem CertName.chain

UNIX

cat CertName.pem X509CA/ca/new_ca.pem> CertName.chain

通过导入证书的完整证书链来更新密钥存储 CertName.jks，如下所示：

keytool -import -file CertName.chain -keypass CertPassword -keystore CertName.jks -storepass CertPassword

重复步骤 2 到 7，为您的系统创建一组完整的证书。

如果您设置了私有 CA，如 第 2.5.2 节 “设置您自己的 CA” 所述，您现在可以创建并签署您自己的证书。

要创建并签署 PKCScriu 格式 CertName.p12 的证书，请执行以下子步骤：

如果您还没有这样做，请在路径中添加 OpenSSL bin 目录，如下所示：

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

此步骤使 openssl 工具可用。

执行此步骤，如果证书面向客户端强制执行 URL 完整性检查的 HTTPS 服务器，如果您计划将服务器部署到多主目录主机或具有多个 DNS 名称别名的主机（例如，如果您要在多重 Web 服务器上部署证书）。在这种情况下，证书身份必须与多个主机名匹配，且只能通过添加 subjectAltName 证书扩展来完成（请参阅 第 2.4 节 “HTTPS 证书的特殊要求”）。

要配置 subjectAltName 扩展，请按如下方式编辑您的 CA 的 openssl.cnf 文件：

为 CertName.p12 证书创建新证书签名请求(CSR)，如下所示：

openssl req -new -config X509CA/openssl.cnf -days 365 -out X509CA/certs/CertName_csr.pem -keyout X509CA/certs/CertName_pk.pem

此命令提示您输入证书的私钥以及证书可分辨名称的信息。

CSR 区分名称中的一些条目必须与 CA 证书中的值匹配（在 openssl.cnf 文件的 CA Policy 部分中指定）。默认 openssl.cnf 文件要求以下条目匹配：

证书主题 DN 的通用名称是通常用于表示证书所有者的身份的字段。通用名称必须满足以下条件：

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
.++
.++
writing new private key to
      'X509CA/certs/CertName_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Systems
Common Name (eg, YOUR name) []:Artix
Email Address []:info@redhat.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:Red Hat

使用您的 CA 为 CSR 签名，如下所示：

openssl ca -config X509CA/openssl.cnf -days 365 -in X509CA/certs/CertName_csr.pem -out X509CA/certs/CertName.pem

此命令需要与 new_ca.pem CA 证书关联的私钥传递短语。例如：

Using configuration from X509CA/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'IE'
stateOrProvinceName :PRINTABLE:'Co. Dublin'
localityName :PRINTABLE:'Dublin'
organizationName :PRINTABLE:'Red Hat'
organizationalUnitName:PRINTABLE:'Systems'
commonName :PRINTABLE:'Bank Server Certificate'
emailAddress :IA5STRING:'info@redhat.com'
Certificate is to be certified until May 24 13:06:57 2000 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

要成功签署证书，您必须输入 CA 私钥密语（请参阅 第 2.5.2 节 “设置您自己的 CA”）。

串联 CA 证书文件、CertName.pem 证书文件和 CertName_pk.pem 私钥文件，如下所示：

Windows

copy X509CA\ca\new_ca.pem + X509CA\certspass:quotes[_CertName_].pem + X509CA\certspass:quotes[_CertName_]_pk.pem X509CA\certspass:quotes[_CertName_]_list.pem

UNIX

cat X509CA/ca/new_ca.pem X509CA/certs/CertName.pem X509CA/certs/CertName_pk.pem > X509CA/certs/CertName_list.pem

从 CertName_list.pem 文件创建一个 PKCScriu 文件，如下所示：

openssl pkcs12 -export -in X509CA/certs/CertName_list.pem -out X509CA/certs/CertName.p12 -name "New cert"

会提示您输入一个密码来加密 PKCScriu 证书。通常，此密码与 CSR 密码相同（这是许多证书存储库要求）。

重复步骤 3 到 6，为您的系统创建一组完整的证书。

当为仅目标身份验证配置了应用程序时，目标会向客户端验证其自身，但客户端并不对目标对象进行身份验证，如 图 3.1 “仅限目标身份验证” 所示。

图 3.1. 仅限目标身份验证

在运行应用程序前，客户端和服务器应设置如下：

在安全握手过程中，服务器将其证书链发送到客户端（请参阅 图 3.1 “仅限目标身份验证”）。然后，客户端搜索其可信 CA 列表，以查找与服务器证书链中的一个 CA 证书匹配的 CA 证书。

在客户端上，仅目标身份验证不需要策略设置。只需配置您的客户端 而不 将 X.509 证书与 HTTPS 端口关联。但是，您必须为客户端提供可信 CA 证书列表（请参阅 第 3.2 节 “指定可信 CA 证书”）。

在服务器端，在服务器的 XML 配置文件中，确保 sec:clientAuthentication 元素不需要客户端身份验证。可以省略此元素，在这种情况下，默认策略 不需要 客户端身份验证。但是，如果存在 sec:clientAuthentication 元素，它应该配置如下：

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...

    <sec:clientAuthentication want="false" required="false"/>
  </http:tlsServerParameters>
</http:destination>

其中 want 属性设置为 false （默认值），指定服务器在 TLS 握手期间不从客户端请求 X.509 证书。required 属性也被设置为 false （默认），指定没有客户端证书在 TLS 握手期间不触发异常。

还需要将 X.509 证书与服务器的 HTTPS 端口关联（请参阅 第 3.3 节 “指定应用程序自己的证书” ），并为服务器提供可信 CA 证书列表（请参阅 第 3.2 节 “指定可信 CA 证书” ）。

当为 mutual 身份验证配置应用程序时，目标会向客户端验证其自身，客户端向目标验证其自身。这个场景在 图 3.2 “双向身份验证” 中进行了说明。在这种情况下，服务器和客户端都需要一个 X.509 证书进行安全握手。

图 3.2. 双向身份验证

在运行应用程序前，客户端和服务器必须设置如下：

在 TLS 握手过程中，服务器将其证书链发送到客户端，客户端将其证书链发送到服务器，请参阅 图 3.1 “仅限目标身份验证”。

在客户端，mutual 身份验证不需要策略设置。只需将 X.509 证书与客户端的 HTTPS 端口关联（请参阅 第 3.3 节 “指定应用程序自己的证书”）。您还需要为客户端提供可信 CA 证书列表（请参阅 第 3.2 节 “指定可信 CA 证书”）。

在服务器端，在服务器的 XML 配置文件中，确保将 sec:clientAuthentication 元素配置为 需要 客户端身份验证。例如：

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...
    <sec:clientAuthentication want="true" required="true"/>
  </http:tlsServerParameters>
</http:destination>

其中 want 属性设为 true，指定服务器在 TLS 握手期间从客户端请求 X.509 证书。required 属性设置为 true，指定没有客户端证书在 TLS 握手期间触发异常。

还需要将 X.509 证书与服务器的 HTTPS 端口关联（请参阅 第 3.3 节 “指定应用程序自己的证书”），并为服务器提供可信 CA 证书列表（请参阅 第 3.2 节 “指定可信 CA 证书”）。

当应用程序在 SSL/TLS 握手过程中收到 X.509 证书时，应用程序会通过检查是否通过检查签发者 CA 是预定义的可信 CA 证书之一来决定是否信任接收的证书。如果收到的 X.509 证书由应用程序的可信 CA 证书有效签名，则证书被视为可信证书；否则，它将被拒绝。

任何可能接收 X.509 证书作为 HTTPS 握手一部分的应用程序都必须指定可信 CA 证书列表。例如，这包括以下类型的应用程序：

CA 证书必须以 Java 密钥存储格式提供。

要为 HTTPS 传输部署一个或多个可信根 CA，请执行以下步骤：

在使用 HTTPS 传输时，使用 XML 配置文件部署应用程序的证书。

要为 HTTPS 传输部署应用程序自己的证书，请执行以下步骤：

通过在 SOAP 编码层而不是传输层应用消息保护，您可以访问更灵活的保护策略。特别是，因为 SOAP 层了解消息结构，您可以在更细致的粒度级别应用保护，例如，只对实际需要保护的标头进行加密和签名。此功能使您能够支持更复杂的多层架构。例如，一个纯文本标头可能位于中间层（位于安全 Iog intranet 中），而加密标头可能位于最终目的地（通过不安全的公共网络访问）。

如 WS-SecurityPolicy 规格中所述，可以使用以下绑定类型之一来保护 SOAP 信息：

以下保护服务质量可应用于部分或所有消息：

这些保护的质量可在单个消息中任意组合。因此，消息的某些部分只能加密，而消息的其他部分则被签名和加密，而消息的其他部分都可以签名和加密。也可以使消息的部分保留为未受保护。

应用消息保护的最灵活的选项位于 SOAP 层(sp:AsymmetricBinding 或 sp:SymmetricBinding)。传输层(sp:TransportBinding)只为您提供 对整个 消息应用保护的选项。

目前，Apache CXF 可让您签名或加密 SOAP 消息的以下部分：

不是消息保护所需的所有详情都使用策略指定。该策略主要用于提供指定服务所需保护质量的方法。必须使用单独的特定于产品的机制提供支持详情，如安全令牌、密码等。实际上，这意味着在 Apache CXF 中，一些支持配置详情必须在蓝图 XML 配置文件中提供。详情请查看 第 6.2.6 节 “提供加密密钥和签名密钥”。

此处描述的场景是一个客户端-服务器应用，其中设置了 非对称绑定策略 来加密和签署在客户端和服务器之间传递消息的 SOAP 正文。

图 6.1 “基本签名和加密场景” 显示了基本签名和加密场景的概述，该场景通过将非对称绑定策略与 WSDL 合同中的端点相关联来指定。

图 6.1. 基本签名和加密场景

当 图 6.1 “基本签名和加密场景” 中的客户端调用接收者端点上的同步操作时，请求和回复消息将按如下方式处理：

非对称绑定策略使用非对称密钥算法（公钥/私钥组合）实施 SOAP 消息保护，并在 SOAP 层执行此类操作。非对称绑定使用的加密和签名算法与 SSL/TLS 使用的加密和签名算法类似。但是，一个重要的区别是 SOAP 消息保护可让您选择消息的特定部分来保护（例如，单个标头、正文或附件），而传输层安全性则只能在 整个 消息上运行。

非对称绑定策略必须应用到端点策略主题（请参阅 “端点策略主题”一节）。例如，给带有 ID 的非对称绑定策略 MutualCertificate10SignEncrypt_IPingService_policy，您可以将策略应用到端点绑定，如下所示：

<wsdl:binding name="MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

AsymmetricBinding 元素具有以下语法：

<sp:AsymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:InitiatorToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorToken>
  ) | (
   <sp:InitiatorSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorSignatureToken>
   <sp:InitiatorEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorEncryptionToken>
  )
  (
   <sp:RecipientToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientToken>
  ) | (
   <sp:RecipientSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientSignatureToken>
   <sp:RecipientEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientEncryptionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:AsymmetricBinding>

例 6.4 “Asymmetric Binding 示例” 显示支持签名和加密消息保护的非对称绑定示例，其中签名和加密是使用公钥/私钥对（即使用非对称加密）进行的。这个示例 没有指定 应签名和加密的消息部分。有关如何进行此操作的详情，请参考 第 6.2.5 节 “指定消息到加密和签名的一部分”。

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:AsymmetricBinding
          xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:InitiatorToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:InitiatorToken>
          <sp:RecipientToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:RecipientToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:AsymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

启动器令牌 引用由启动器拥有的公钥/私钥对。这个令牌如下：

混淆，此令牌被启动器 和 接收者同时使用。但是，只有启动器有权访问私钥，因此可以说该令牌属于发起方。在 第 6.2.2 节 “基本签名和加密场景” 中，启动器令牌是证书 alice。

此元素应包含嵌套的 wsp:Policy 元素和 sp:X509Token 元素，如下所示。sp:IncludeToken 属性设置为 AlwaysToRecipient，它指示运行时包含 alice 的公钥，每个消息发送到接收者。如果接收者希望使用启动器的证书执行身份验证，则此选项很有用。最深入的嵌套元素 WssX509V3Token10 是可选的。它指定 X.509 证书应符合哪些规格版本。您可以在此处指定以下替代方案（或 none）：

接收者令牌 引用由接收者拥有的公钥/私钥对。这个令牌如下：

混淆，此令牌被接收者 和 发起方同时使用。但是，只有接收者有权访问私钥，因此这个令牌可以被认为属于接收者。在 第 6.2.2 节 “基本签名和加密场景” 中，接收者令牌是证书ob。

此元素应包含嵌套的 wsp:Policy 元素和 sp:X509Token 元素，如下所示。sp:IncludeToken 属性设置为 Never，因为不需要在回复消息中包含 bob 的公钥。

此元素指定用于签名和加密的加密算法套件。有关可用算法套件的详情，请参考 第 6.2.7 节 “指定算法套件”。

此元素指定是否对将安全标头添加到 SOAP 消息的顺序实施任何条件。sp:Lax 元素指定不会对安全标头顺序实施任何条件。sp:Lax 的替代方案是 sp:Strict,sp:LaxTimestampFirst, 或 sp:LaxTimestampLast。

如果策略中包含此元素，则运行时会在 wsse:Security 标头中添加 wsu:Timestamp 元素。默认情况下，不会包含 时间戳。

如果消息部分同时受到加密和签名的影响，则需要指定这些操作的执行顺序。默认顺序是加密前的签名。但是，如果您在非对称策略中包含此元素，则顺序将更改为加密，然后再签名。

这个元素指定消息签名必须加密（通过加密令牌，如 第 6.2.6 节 “提供加密密钥和签名密钥”所述）。默认值为 false。

此元素指定签名必须覆盖用于生成该签名的令牌。默认值为 false。

此元素指定签名 只能 应用到整个正文或整个标头，不适用于标头的正文或子元素的子元素。当启用这个选项时，您可以有效地阻止使用 sp:SignedElements assertion （请参阅 第 6.2.5 节 “指定消息到加密和签名的一部分”）。

对称绑定策略使用对称密钥算法（共享密钥密钥）实施 SOAP 消息保护，并在 SOAP 层执行此操作。对称绑定的示例是 Kerberos 协议和 WS-SecureConversation 协议。

对称绑定策略必须应用到端点策略主题（请参阅 “端点策略主题”一节）。例如，给带有 ID 的对称绑定策略，SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy，您可以将策略应用到端点绑定，如下所示：

<wsdl:binding name="SecureConversation_MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

SymmetricBinding 元素具有以下语法：

<sp:SymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:EncryptionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:EncryptionToken>
   <sp:SignatureToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:SignatureToken>
  ) | (
   <sp:ProtectionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:ProtectionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:SymmetricBinding>

例 6.5 “Symmetric Binding 示例” 显示支持签名和加密的消息保护的对称绑定示例，其中签名和加密是使用单个对称密钥（即使用对称加密）完成的。这个示例 没有指定 应签名和加密的消息部分。有关如何进行此操作的详情，请参考 第 6.2.5 节 “指定消息到加密和签名的一部分”。

<wsp:Policy wsu:Id="SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:SecureConversationToken>
                ...
              </sp:SecureConversationToken>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
      ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

此元素指定用于签名和加密消息的对称令牌。例如，您可以在此处指定 WS-SecureConversation 令牌。

如果要使用不同的令牌来签名和加密操作，请使用 sp:SignatureToken 元素和 sp:EncryptionToken 元素来代替此元素。

此元素指定用于签名消息的对称令牌。它应与 sp:EncryptionToken 元素结合使用。

此元素指定用于加密消息的对称令牌。它应与 sp:SignatureToken 元素结合使用。

此元素指定用于签名和加密的加密算法套件。有关可用算法套件的详情，请参考 第 6.2.7 节 “指定算法套件”。

此元素指定是否对将安全标头添加到 SOAP 消息的顺序实施任何条件。sp:Lax 元素指定不会对安全标头顺序实施任何条件。sp:Lax 的替代方案是 sp:Strict,sp:LaxTimestampFirst, 或 sp:LaxTimestampLast。

如果策略中包含此元素，则运行时会在 wsse:Security 标头中添加 wsu:Timestamp 元素。默认情况下，不会包含 时间戳。

当消息部分同时受到加密和签名时，必须指定执行这些操作的顺序。默认顺序是加密前的签名。但是，如果您在对称策略中包含此元素，则顺序将更改为加密，然后再签名。

此元素指定消息签名必须加密。默认值为 false。

此元素指定签名必须覆盖用于生成该签名的令牌。默认值为 false。

此元素指定签名 只能 应用到整个正文或整个标头，不适用于标头的正文或子元素的子元素。当启用这个选项时，您可以有效地阻止使用 sp:SignedElements assertion （请参阅 第 6.2.5 节 “指定消息到加密和签名的一部分”）。

加密和签名提供两种保护类型：机密性和完整性。WS-SecurityPolicy 保护断言用于指定消息中 哪些 部分受到保护。另一方面，保护机制的详情在相关绑定策略中单独指定（请参阅 x第 6.2.3 节 “指定 AsymmetricBinding 策略”、第 6.2.4 节 “指定 SymmetricBinding 策略” 和 第 6.1 节 “传输层安全性消息保护”）。

此处描述的保护断言实际上设计为与 SOAP 安全性结合使用，因为它们适用于 SOAP 消息的功能。然而，这些策略也可以被传输绑定（如 HTTPS）满足，后者 对整个 消息应用保护，而不是特定部分。

保护断言必须应用到 消息策略主题 （请参阅 “消息策略主题”一节）。换句话说，它必须放在 WSDL 绑定中的 wsdl:input、wsdl:output 或 wsdl:fault 元素中。例如，给定 ID 的保护策略，Mu tualCertificate10SignEncrypt_IPingService_header_Input_policy，您可以将策略应用到 wsdl:input 消息部分，如下所示：

<wsdl:operation name="header">
  <soap:operation soapAction="http://InteropBaseAddress/interop/header" style="document"/>
  <wsdl:input name="headerRequest">
    <wsp:PolicyReference
        URI="#MutualCertificate10SignEncrypt_IPingService_header_Input_policy"/>
      <soap:header message="i0:headerRequest_Headers" part="CustomHeader" use="literal"/>
      <soap:body use="literal"/>
    </wsdl:input>
    ...
</wsdl:operation>

Apache CXF 支持以下 WS-SecurityPolicy 保护断言：

SignedParts 元素的语法如下：

<sp:SignedParts xmlns:sp="..." ... >
  <sp:Body />?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:SignedParts>

EncryptedParts 元素的语法如下：

<sp:EncryptedParts xmlns:sp="..." ... >
  <sp:Body/>?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:EncryptedParts>

例 6.6 “完整性和加密策略建议” 显示组合了两个保护断言的策略：签名部分断言和一个加密部分断言。当此策略应用到消息部分时，受影响的消息正文会被签名并加密。另外，名为 CustomHeader 的消息标头被签名。

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_header_Input_policy">
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
                <sp:Header Name="CustomHeader" Namespace="http://InteropBaseAddress/interop"/>
            </sp:SignedParts>
            <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
            </sp:EncryptedParts>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

此元素指定保护（加密或签名）应用于消息的正文。保护应用于 整个 消息正文：即 soap:Body 元素、其属性及其内容。

此元素指定保护应用于由标头的本地名称、使用 Name 属性和 namespace 指定的 SOAP 标头，使用 Namespace 属性。保护应用于 整个 消息标头，包括其属性及其内容。

此元素指定所有带有附件(SwA)附件的 SOAP 都受到保护。

标准 WS-SecurityPolicy 策略旨在在一些详细信息中指定 安全要求 ：例如，安全协议、安全算法、令牌类型、身份验证要求等。但是，标准策略断言不提供指定关联的安全数据的任何机制，如密钥和凭证。WS-SecurityPolicy 期望通过专有机制提供必要的安全数据。在 Apache CXF 中，相关的安全数据通过 Blueprint XML 配置提供。

您可以通过在客户端的请求上下文或端点上下文中设置属性来指定应用程序的加密密钥和签名密钥（请参阅 “在 Blueprint 配置中添加加密和签名属性”一节）。您可以设置的属性显示在 表 6.1 “加密和签名属性” 中。

以上属性的名称不会被充分选择，因为它们无法准确反映它们的用途。由 security.signature.properties 指定的密钥实际上用于签名 和 解密。由 security.encryption.properties 指定的密钥实际上被用来加密和验证签名。

在 Apache CXF 应用程序中使用任何 WS-Policy 策略前，您必须将策略功能添加到默认的 CXF 总线中。在 CXF 总线中添加 p:policies 元素，如以下 Blueprint 配置片段所示：

<beans xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:cxf="http://cxf.apache.org/core"
       xmlns:p="http://cxf.apache.org/policy" ... >

    <cxf:bus>
        <cxf:features>
            <p:policies/>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus>
    ...
</beans>

以下示例演示了如何将签名和加密属性添加到指定服务类型的代理（通过 jaxws:client 元素的 name 属性指定服务名称）。属性存储在 WSS4J 属性文件中，其中 alice.properties 包含签名密钥和 bob.properties 的属性，包含加密密钥的属性。

<beans ... >
    <jaxws:client name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
                  createdFromAPI="true">
        <jaxws:properties>
            <entry key="ws-security.signature.properties" value="etc/alice.properties"/>
            <entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
        </jaxws:properties>
    </jaxws:client>
    ...
</beans>

实际上，虽然属性名称中没有明显，但每个键都用于客户端上的两个不同的目的：

如果您发现这个混淆，请参阅 第 6.2.2 节 “基本签名和加密场景” 以获得更详细的说明。

以下示例演示了如何向 JAX-WS 端点添加签名和加密属性。属性文件 bob.properties 包含签名密钥和属性文件 alice.properties 的属性，包含加密密钥的属性（这是客户端配置）。

<beans ... >
    <jaxws:endpoint
       name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
       id="MutualCertificate10SignEncrypt"
       address="http://localhost:9002/MutualCertificate10SignEncrypt"
       serviceName="interop:PingService10"
       endpointName="interop:MutualCertificate10SignEncrypt_IPingService"
       implementor="interop.server.MutualCertificate10SignEncrypt">

        <jaxws:properties>
            <entry key="security.signature.properties" value="etc/bob.properties"/>
            <entry key="security.encryption.properties" value="etc/alice.properties"/>
        </jaxws:properties>

    </jaxws:endpoint>
    ...
</beans>

每个密钥都用于服务器端的两个不同目的：

Apache CXF 使用 WSS4J 属性文件来加载加密和签名所需的公钥和私钥。表 6.2 “WSS4J 密钥存储属性” 描述您可以在这些文件中设置的属性。

例如，etc/alice.properties 文件包含用于加载 PKCScriu 文件 certs/alice.pfx 的属性设置，如下所示：

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.file=certs/alice.pfx

etc/bob.properties 文件包含用于加载 PKCSFILTER 文件 certs/bob.pfx 的属性设置，如下所示：

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.password=password

# for some reason, bouncycastle has issues with bob.pfx
org.apache.ws.security.crypto.merlin.keystore.provider=SunJSSE
org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.file=certs/bob.pfx

加载加密密钥和签名密钥的替代方法是使用 表 6.3 “指定 Crypto 对象的属性” 中显示的属性来指定载入相关密钥的 Crypto 对象。这要求您自己实现 WSS4J Crypto 接口 org.apache.ws.security.components.crypto.Crypto。

例 6.7 “WSS4J Crypto Interface” 如果要通过编程提供加密密钥和签名密钥，显示您可以实现的 Crypto 接口的定义。如需更多信息，请参阅 WSS4J 主页。

// Java
package org.apache.ws.security.components.crypto;

import org.apache.ws.security.WSSecurityException;

import java.io.InputStream;
import java.math.BigInteger;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;

public interface Crypto {
    X509Certificate loadCertificate(InputStream in)
    throws WSSecurityException;

    X509Certificate[] getX509Certificates(byte[] data, boolean reverse)
    throws WSSecurityException;

    byte[] getCertificateData(boolean reverse, X509Certificate[] certs)
    throws WSSecurityException;

    public PrivateKey getPrivateKey(String alias, String password)
    throws Exception;

    public X509Certificate[] getCertificates(String alias)
    throws WSSecurityException;

    public String getAliasForX509Cert(Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer, BigInteger serialNumber)
    throws WSSecurityException;

    public String getAliasForX509Cert(byte[] skiBytes)
    throws WSSecurityException;

    public String getDefaultX509Alias();

    public byte[] getSKIBytesFromCert(X509Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509CertThumb(byte[] thumb)
    throws WSSecurityException;

    public KeyStore getKeyStore();

    public CertificateFactory getCertificateFactory()
    throws WSSecurityException;

    public boolean validateCertPath(X509Certificate[] certs)
    throws WSSecurityException;

    public String[] getAliasesForDN(String subjectDN)
    throws WSSecurityException;
}

算法套件是执行操作（如签名、加密、生成消息摘要等）的加密算法的一致性集合。

为了便于参考，本节描述了 WS-SecurityPolicy 规格定义的算法套件。但是，是否一个特定的算法套件可用，但取决于底层的安全供应商。Apache CXF 安全性基于可插拔 Java Cryptography 扩展(JCE)和 Java 安全套接字扩展(JSSE)层。默认情况下，Apache CXF 配置有 Sun 的 JSSE 供应商，它支持 Sun 的 JSSE 附录 A 附录 A 中所述的密码套件。

AlgorithmSuite 元素的语法如下：

<sp:AlgorithmSuite xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
   (<sp:Basic256 ... /> |
    <sp:Basic192 ... /> |
    <sp:Basic128 ... /> |
    <sp:TripleDes ... /> |
    <sp:Basic256Rsa15 ... /> |
    <sp:Basic192Rsa15 ... /> |
    <sp:Basic128Rsa15 ... /> |
    <sp:TripleDesRsa15 ... /> |
    <sp:Basic256Sha256 ... /> |
    <sp:Basic192Sha256 ... /> |
    <sp:Basic128Sha256 ... /> |
    <sp:TripleDesSha256 ... /> |
    <sp:Basic256Sha256Rsa15 ... /> |
    <sp:Basic192Sha256Rsa15 ... /> |
    <sp:Basic128Sha256Rsa15 ... /> |
    <sp:TripleDesSha256Rsa15 ... /> |
    ...)
    <sp:InclusiveC14N ... /> ?
    <sp:SOAPNormalization10 ... /> ?
    <sp:STRTransform10 ... /> ?
   (<sp:XPath10 ... /> |
    <sp:XPathFilter20 ... /> |
    <sp:AbsXPath ... /> |
    ...)?
    ...
  </wsp:Policy>
  ...
</sp:AlgorithmSuite>

该算法套件断言支持大量替代算法（如 Basic256）。有关算法套件替代方案的详细描述，请参阅 表 6.4 “算法套件”。

表 6.4 “算法套件” 提供 WS-SecurityPolicy 支持的算法套件摘要。列标题引用不同类型的加密算法，如下所示：\[Dig] 是摘要算法；\[Enc] 是加密算法；\[Sym KW] 是对称密钥包装算法；\[Asym KW] 是非对称密钥包装算法；\[Enc KD] 是加密密钥算法；\[Sig KD] 是签名密钥派生算法。

WS-SecurityPolicy 支持以下加密算法类型：

对称密钥签名属性 [Sym Sig] 指定使用对称密钥生成签名的算法。WS-SecurityPolicy 指定总是使用 HmacSha1 算法。

HmacSha1 算法由以下 URI 标识：

http://www.w3.org/2000/09/xmldsig#hmac-sha1

非对称密钥签名属性 [Asym Sig] 指定使用非对称密钥生成签名的算法。WS-SecurityPolicy 指定始终使用 RsaSha1 算法。

RsaSha1 算法由以下 URI 标识：

http://www.w3.org/2000/09/xmldsig#rsa-sha1

digest 属性 [Dig] 指定用于生成消息摘要值的算法。WS-SecurityPolicy 支持两种替代摘要算法： Sha1 和 Sha256。

Sha1 算法由以下 URI 标识：

http://www.w3.org/2000/09/xmldsig#sha1

Sha256 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#sha256

加密属性 [Enc] 指定用于加密数据的算法。WS-SecurityPolicy 支持以下加密算法： Aes256,Aes192,Aes128,TripleDes.

Aes256 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#aes256-cbc

Aes192 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#aes192-cbc

Aes128 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#aes128-cbc

TripleDes 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

symmetric key wrap 属性 [Sym KW] 指定用于签名和加密对称密钥的算法。WS-SecurityPolicy 支持以下对称密钥嵌套算法： KwAes256,KwAes192,KwAes128,KwTripleDes.

KwAes256 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#kw-aes256

KwAes192 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#kw-aes192

KwAes128 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#kw-aes128

KwTripleDes 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

非对称密钥嵌套属性 [Asym KW] 指定用于签名和加密非对称密钥的算法。WS-SecurityPolicy 支持以下非对称密钥嵌套算法： KwRsaOaep,KwRsa15。

KwRsaOaep 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

KwRsa15 算法由以下 URI 标识：

http://www.w3.org/2001/04/xmlenc#rsa-1_5

computed 键属性 [Comp Key] 指定用于计算派生密钥的算法。当安全方与共享 secret 密钥的帮助（例如，使用 WS-SecureConversation）通信时，建议使用派生的密钥而不是原始共享密钥，以避免公开太多数据以供恶意第三方进行分析。WS-SecurityPolicy 指定 PSha1 算法始终被使用。

PSha1 算法由以下 URI 标识：

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

加密密钥 derivation 属性 [Enc KD] 指定用于计算派生加密密钥的算法。WS-SecurityPolicy 支持以下加密密钥派生算法： PSha1L256、PSha1L192、PSha1L128.

PSha1 算法由以下 URI 标识（相同的算法用于 PSha1L256、PSha1L192 和 PSha1L128 ；只有密钥长度不同）：

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

签名密钥派生属性 [Sig KD] 指定用于计算派生签名密钥的算法。WS-SecurityPolicy 支持以下签名密钥派生算法： PSha1L192,PSha1L128.

表 6.5 “密钥长度属性” 显示 WS-SecurityPolicy 中支持的最小和最大密钥长度。

最小对称密钥长度 [Min SKL] 的值取决于所选的算法套件。