Sun Java System Application Server Enterprise Edition 8.2 管理指南

第 10 章 配置消息安全性

本章中的某些内容假定您已对安全性和 Web 服务概念有了基本的了解。要详细了解这些概念,请在开始阅读本章之前先仔细阅读更多信息中列出的资源。

本章介绍如何在 Application Server 中为 Web 服务配置消息层的安全性。本章包含以下主题:

消息安全性概述

消息安全性中,安全性信息被插入到消息中以使其通过网络层传输,并和消息一起到达消息目的地。消息安全性与传输层安全性不同(在《The J2EE 1.4 Tutorial》的“Security”一章中有说明),这是因为消息安全性可用于将消息保护从消息传输中分离开,从而使消息在传输后仍保持被保护状态。

Web 服务安全性:SOAP 消息安全性 (WS-Security) 是可交互使用的 Web 服务安全性的国际标准,是在 OASIS 中由所有 Web 服务技术的主要提供商(包括 Sun Microsystems)协作开发的。WS-Security 是一种消息安全性机制,它使用 XML 加密和 XML 数字签名来确保 SOAP 上发送的 Web 服务消息的安全。WS-Security 规范定义了多种安全令牌(包括 X.509 证书、SAML 断言和用户名/密码令牌)的用途,以验证和加密 SOAP Web 服务消息。

可以在 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message -security-1.0.pdf 中查看 WS-Security 规范。

了解 Application Server 中的消息安全性

Application Server 将对 WS-Security 标准的支持集成至其 Web 服务客户机和服务器端容器。集成此功能,可以使 Web 服务安全性由代表应用程序的 Application Server 的容器强制执行,并且可以将其应用于保护任何 Web 服务应用程序而无需对应用程序的实现进行更改。Application Server 通过提供工具将 SOAP 层消息安全性提供者和消息保护策略绑定到容器和容器中部署的应用程序来达到该效果。

指定消息安全性职责

在 Application Server 中,系统管理员应用程序部署者角色应承担配置消息安全性的主要责任。尽管通常情况下,其他两个角色中的任意一个在无需更改现有应用程序实现的情况下就可以确保应用程序的安全而不必涉及开发者,但在某些情况下,应用程序开发者还是会有所作用的。以下小节定义了各种角色的职责:

系统管理员

系统管理员负责:

系统管理员使用管理控制台来管理服务器安全性设置,并使用命令行工具来管理证书数据库。在平台版中,证书和专用密钥存储在密钥库中,并通过 keytool 进行管理。标准版和企业版将证书和专用密钥存储在 NSS 数据库中,并使用 certutil 进行管理。本文档主要针对系统管理员。有关消息安全性任务的概述,请参见为消息安全性配置 Application Server

应用程序部署者

应用程序部署者负责:

Developers’ Guide》 的“Securing Applications”一章中讨论了这些安全性任务。有关指向该章的链接,请参见更多信息

应用程序开发者

应用程序开发者可以打开消息安全性,但并不是必须要这样做。消息安全性可以由系统管理员设置,从而确保所有 Web 服务的安全;或者由应用程序部署者设置,这适用于绑定到应用程序的提供者或保护策略与绑定到容器的提供者或保护策略不同的情况。

应用程序开发者或汇编者负责:

关于安全令牌和安全机制

WS-Security 规范为使用安全令牌来验证和加密 SOAP Web 服务消息提供了可扩展机制。可以使用与 Application Server 一起安装的 SOAP 层消息安全性提供者来利用用户名/密码和 X.509 证书安全性令牌来对 SOAP Web 服务消息进行验证和加密。利用其他安全令牌(包括 SAML 断言)的其他提供者将与 Application Server 的后续版本一起安装。

关于用户名令牌

Application Server 使用 SOAP 消息中的用户名令牌来建立消息发件人的验证标识。包含用户名令牌(在嵌入式密码中)的消息的收件人通过确认发件人是否知道用户的秘密(密码),来验证消息发件人是否为经过授权的用户(在令牌中标识)。

使用用户名令牌时,必须在 Application Server 中配置有效的用户数据库。

关于数字签名

Application Server 使用 XML 数字签名将验证标识绑定到消息内容中。客户机使用数字签名来建立它们的呼叫者标识,其方法与使用传输层安全性时用基本验证或 SSL 客户机证书验证建立呼叫者标识的方法相似。消息收件人将检验数字签名以验证消息内容的源(可能与消息的发件人不同)。

使用数字签名时,必须在 Application Server 中配置有效的密钥库和信任库文件。有关此主题的更多信息,请参见关于证书文件

关于加密

加密的目的是将数据修改为只有目标读者能理解的形式。加密过程通过用加密元素代替原始内容来完成。像公共密钥加密指出的那样,可以使用加密来建立能够阅读消息的一方或多方的标识。

使用加密时,必须先安装支持加密的 JCE 提供者。有关此主题的更多信息,请参见配置 JCE 提供者

关于消息保护策略

消息保护策略是针对请求消息处理和响应消息处理而定义的,并根据对源和/或收件人验证的要求来进行表达。源验证策略代表一个请求,即在消息中建立发送了消息或定义了消息内容的实体的标识,以使其可以由消息收件人进行验证。收件人验证策略代表一个请求,即发送消息,以使可以接收消息的实体的标识可以由消息发件人建立。提供者将应用特定的消息安全性机制以使消息保护策略在 SOAP Web 服务消息的上下文中实现。

在给容器配置提供者时,将定义请求和响应的消息保护策略。特定于应用程序的消息保护策略(以 Web 服务端口或操作的粒度级别)也可以在应用程序或应用程序客户机端的特定于 Sun 的部署描述符中进行配置。在任何情况下,如果定义了消息保护策略,则客户机请求和响应的消息保护策略必须与服务器请求和响应的消息保护策略相匹配(二者相当)。有关定义特定于应用程序的消息保护策略的更多信息,请参见《Developer’ s Guide》的“Securing Applications”一章。

消息安全性术语表

以下介绍了此文档中所用到的术语。此外,为消息安全性配置 Application Server 中还讨论了相关概念。

确保 Web 服务的安全

通过将 SOAP 层消息安全性提供者和消息保护策略绑定到部署有应用程序的容器或绑定到应用程序提供的 Web 服务端点,来确保在 Application Server 中部署的 Web 服务的安全。通过将 SOAP 层消息安全性提供者和消息保护策略绑定到客户机容器或绑定到由客户机应用程序声明的可移植服务引用,从而在 Application Server 的客户机端容器中配置 SOAP 层消息安全性功能。

安装了 Application Server 后,将在 Application Server 的客户机和服务器端容器中配置 SOAP 层消息安全性提供者,这些提供者可由容器或容器中部署的各个应用程序或客户机进行绑定使用。在安装过程中,这些提供者将配置简单的消息保护策略,即如果被绑定到容器或者绑定到容器中的应用程序或客户机,将导致所有请求和响应消息中的内容源由 XML 数字签名进行验证。

可以采用 Application Server 的管理界面来绑定现有提供者以便供 Application Server 的服务器端容器使用,修改由提供者强制执行的消息保护策略,或使用替代的消息保护策略来创建新的提供者配置。可以对应用程序客户机端容器的 SOAP 消息层安全性配置执行类似的管理操作,如启用应用程序客户机端的消息安全性中所定义。

默认情况下,Application Server 中的消息层安全性处于禁用状态。要为 Application Server 配置消息层安全性,请按照为消息安全性配置 Application Server 中列出的步骤进行操作。如果您要使 Web 服务安全性用于保护在 Application Server 上部署的所有 Web 服务应用程序,请按照启用消息安全性提供者中的步骤进行操作。

完成以上步骤(可能包括重新启动 Application Server)后,Web 服务安全性将应用到 Application Server 中部署的所有 Web 服务应用程序。

配置特定于应用程序的 Web 服务安全性

通过在应用程序的特定于 Sun 的部署描述符中定义 message-security-binding 元素,可以配置特定于应用程序的 Web 服务安全性功能(在应用程序汇编时)。这些 message-security-binding 元素用于将特定提供者或消息保护策略与 Web 服务端点或服务引用相关联,并可以被限定以使这些元素应用到相应端点或引用服务的特定端口或方法。

有关定义特定于应用程序的消息保护策略的更多信息,请参见《Developer’ s Guide 》的“Securing Applications”一章。更多信息中有指向该章的链接。

确保样例应用程序的安全

Application Server 附带了名为 xms 的样例应用程序。xms 应用程序具有简单的 Web 服务功能,它由 J2EE EJB 端点和 Java Servlet 端点共同实现。这两个端点共享同一个服务端点接口。服务端点接口定义了单个操作 sayHello,此操作将获取一个字符串参数,并将由前置 Hello 组成的 String 返回到调用参数中。

提供的 xms 样例应用程序用来演示 Application Server 的 WS-Security 功能的用途,以确保现有 Web 服务应用程序的安全。样例附带的说明介绍了如何启用 Application Server 的 WS-Security 功能以使其用于确保 xms 应用程序的安全。样例还演示如何向应用程序直接绑定 WS-Security 功能(如配置特定于应用程序的 Web 服务安全性中所述)。

xms 样例应用程序安装在以下目录中:install-dir/samples/webservices/security/ejb/apps/xms/

有关编译、封装和运行 xms 样例应用程序的信息,请参见《Developers’ Guide》的“Securing Applications”一章。

为消息安全性配置 Application Server

请求策略配置和响应策略配置的操作

下表显示了消息保护策略配置以及由 WS-Security SOAP 消息安全性提供者针对该配置所执行的最终消息安全性操作。

表 10–1 消息保护策略与 WS-Security SOAP 消息安全性操作的映射

消息保护策略 

最终的 WS-Security SOAP 消息保护操作 

auth-source="sender" 

此消息包含 wsse:Security 标头,此标头包含 wsse:UsernameToken(带有密码)。

auth-source="content" 

对 SOAP 消息主体的内容进行签名。此消息包含 wsse:Security,此标头包含显示为 ds:Signature 的消息主体签名。

auth-source="sender" 

auth-recipient="before-content" 

或 

auth-recipient="after-content" 

SOAP 消息主体的内容已加密并用最终的 xend:EncryptedData 替换。此消息包含 a wsse:Security 标头,此标头包含 wsse:UsernameToken(带有密码)xenc:EncryptedKeyxenc:EncryptedKey 包含用于对 SOAP 消息主体进行加密的密钥。此密钥在收件人的公共密钥中加密。

auth-source="content" 

auth-recipient="before-content" 

SOAP 消息主体的内容已加密并用最终的 xend:EncryptedData 替换。对 xenc:EncryptedData 进行签名。此消息包含 a wsse:Security 标头,此标头包含 xenc:EncryptedKeyds:Signaturexenc:EncryptedKey 包含用于对 SOAP 消息主体进行加密的密钥。此密钥在收件人的公共密钥中加密。

auth-source="content" 

auth-recipient="after-content" 

对 SOAP 消息主体的内容进行签名、加密,并用最终的 xend:EncryptedData 替换。此消息包含 wsse:Security 标头,此标头包含 xenc:EncryptedKeyds:Signaturexenc:EncryptedKey 包含用于对 SOAP 消息主体进行加密的密钥。此密钥在收件人的公共密钥中加密。

auth-recipient="before-content" 

或 

auth-recipient="after-content" 

SOAP 消息主体的内容已加密并用最终的 xend:EncryptedData 替换。此消息包含 a wsse:Security 标头,此标头包含 xen:EncryptedKeyxenc:EncryptedKey 包含用于对 SOAP 消息主体进行加密的密钥。此密钥在收件人的公共密钥中加密。

未指定策略。 

模块未执行任何安全操作。 

配置其他安全性工具

Application Server 使用在其 SOAP 处理层中集成的消息安全性提供者来实现消息安全性。消息安全性提供者取决于 Application Server 的其他安全性工具。

  1. 如果使用的 Java SDK 的版本早于 1.5.0,而且使用了加密技术,请配置 JCE 提供者。

  2. 配置 JCE 提供者中说明了如何配置 JCE 提供者。

  3. 如果使用了用户名令牌,请在必要时配置用户数据库。使用用户名/密码令牌时,必须配置适当的区域并为该区域配置适当的用户数据库。

  4. 管理证书和专用密钥(如有必要)。

完成之后

将 Application Server 的工具配置为供消息安全性提供者使用后,则可启用随 Application Server 一起安装的提供者,如启用消息安全性提供者中所述。

配置 JCE 提供者

J2SE 1.4.x 中包含的 Java 加密扩展 (JCE) 提供者不支持RSA 加密。由于由 WS-Security 所定义的 XML 加密通常是基于 RSA 加密,因此为了使用 WS-Security 来加密 SOAP 消息,您必须下载并安装支持 RSA 加密的 JCE 提供者。


注 –

RSA 是 RSA Data Security, Inc. 开发的公共密钥加密技术。RSA 缩略词分别代表该技术的三位发明者:Rivest、Shamir 和 Adelman。


如果是在 1.5 版的 Java SDK 中运行 Application Server,则已正确配置了 JCE 提供者。如果是在 1.4.x 版的 Java SDK 中运行 Application Server,您可以静态方式将 JCE 提供者添加为 JDK 环境的一部分,如下所示。

  1. 下载并安装 JCE 提供者 JAR(Java 归档)文件。

    通过以下 URL 可以获得支持 RSA 加密的 JCE 提供者的列表:http://java.sun.com/products/jce/jce14_providers.html

  2. 将 JCE 提供者 JAR 文件复制到 java-home/jre/lib/ext/ 中。

  3. 停止 Application Server。

    如果未停止 Application Server 而后来又在这一过程中重新启动了 Application Server,则 Application Server 将无法识别 JCE 提供者。

  4. 在任何一种文本编辑器中编辑 java-home/jre/lib/security/java.security 属性文件。将刚才下载的 JCE 提供者添加到此文件。

    java.security 文件包含添加此提供者的详细说明。通常,您需要在具有类似属性的某个位置处添加一行,其格式如下:


    security.provider.n=provider-class-name
    

    在本示例中,n 是 Application Server 评估安全性提供者时使用的优先级顺序。为刚才添加的 JCE 提供者将 n 设置为 2

    例如,如果您下载的是 Legion of the Bouncy Castle JCE 提供者,则应添加以下行。


    security.provider.2=org.bouncycastle.jce.provider.
       BouncyCastleProvider

    确保将 Sun 安全性提供者保持在最高优先级,值为 1。


    security.provider.1=sun.security.provider.Sun

    将其他安全性提供者的优先级调低,从而使每个优先级上只有一个安全性提供者。

    以下是提供所需 JCE 提供者并将现有提供者保持在正确位置的 java.security 文件的示例。


    security.provider.1=sun.security.provider.Sun
    security.provider.2=org.bouncycastle.jce.provider.
       BouncyCastleProvider
    security.provider.3=com.sun.net.ssl.internal.ssl.Provider
    security.provider.4=com.sun.rsajca.Provider
    security.provider.5=com.sun.crypto.provider.SunJCE
    security.provider.6=sun.security.jgss.SunProvider
  5. 保存并关闭文件。

  6. 重新启动 Application Server。

消息安全性设置

为使用消息安全性而对 Application Server 进行设置的大部分步骤都可以通过使用管理控制台、asadmin 命令行工具或通过手动编辑系统文件来完成。通常,建议不要通过编辑系统文件来完成,因为它可能会导致出现无意的更改而使 Application Server 不能正常运行,所以,如有可能,建议优先使用管理控制台来配置 Application Server,其次选用 asadmin 工具命令。仅在无管理控制台或等效的 asadmin 时,才通过手动编辑系统文件来完成。

对消息层安全性的支持以(可插入)验证模块的形式集成到 Application Server 及其客户机容器中。默认情况下,Application Server 中的消息层安全性处于禁用状态。以下各节提供了启用、创建、编辑和删除消息安全性配置和提供者的详细信息。

大多数情况下,在执行以上列出的管理操作后应重新启动 Application Server。它尤其适用于当执行完操作时,您要将管理更改的效果应用到 Application Server 上已部署的应用程序中的情况。

启用消息安全性提供者

要为在 Application Server 中部署的 Web 服务端点启用消息安全性,必须指定要在服务器端默认使用的提供者。如果为消息安全性启用了默认提供者,您还需要启用要由 Application Server 中部署的 Web 服务客户机所使用的提供者。启用应用程序客户机端的消息安全性中介绍了有关启用客户机使用的提供者的信息。

要为源于已部署的端点的 Web 服务调用启用消息安全性,您必须指定默认客户机提供者。如果已为 Application Server 启用了默认客户机提供者,则必须确保从 Application Server 中部署的端点中调用的所有服务均已配置为与消息层安全性兼容。

使用命令行实用程序:

配置消息安全性提供者

通常,应重新配置提供者以修改其消息保护策略,当然提供者类型、实现类和特定于提供者的配置属性可能也需要修改。

可以使用命令行实用程序设置响应策略,将以下命令中的文字 request 替换为 response

创建消息安全性提供者

要使用管理控制台配置现有提供者,请选择“配置”节点>要配置的实例>“安全性”节点>“消息安全性”节点> "SOAP" 节点>“提供者”选项卡。

有关创建消息安全性提供者的更多详细说明,请参见管理控制台联机帮助。

启用应用程序客户机端的消息安全性

必须配置客户机提供者的消息保护策略,以使其等效于将与其进行交互的服务器端提供者的消息保护策略。在安装 Application Server 时已配置(但未启用)的提供者已符合此情况。

要启用客户机应用程序的消息安全性,请修改应用程序客户机端容器特定于 Application Server 的配置。

设置应用程序客户机端配置的请求策略和响应策略

请求策略和响应策略定义与验证提供者执行的请求处理和响应处理关联的验证策略要求。按照消息发件人的顺序表达这些策略,从而使内容之后出现的加密请求表示消息收件人将在验证签名之前先要对消息进行解密。

要获得消息安全性,必须既在服务器中也在客户机中启用请求策略和响应策略。在客户机和服务器中配置策略时,请确保请求/响应应用程序级别消息绑定的保护的客户机策略与服务器策略匹配。

要设置应用程序客户机端配置的请求策略,请按启用应用程序客户机端的消息安全性中所述,修改应用程序客户机端容器特定于 Application Server 的配置。在应用程序客户机端配置文件中,按所示添加 request-policyresponse-policy 元素设置请求策略。

提供的其他代码可用作参考。您的安装中的其他代码可能会稍有不同。请勿对其进行更改。


<client-container>
  <target-server name="your-host" address="your-host"
      port="your-port"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP"
      default-client-provider="ClientProvider">
    <provider-config
        class-name="com.sun.enterprise.security.jauth.ClientAuthModule"
        provider-id="ClientProvider" provider-type="client">
      <request-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
      <response-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
       <property name="security.config"
           value="install-dir/lib/appclient/wss-client-config.xml"/>
    </provider-config>
  </message-security-config>
</client-container>

auth-source 的有效值包括 sendercontentauth-recipient 的有效值包括 before-contentafter-content请求策略配置和响应策略配置的操作中包含一个表,用于说明这些值的各种组合的结果。

如果不想指定请求策略或响应策略,请将该元素保留为空,例如:


<response-policy/>

更多信息