test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理指南

关于 Application Server 安全性

安全性概述

安全性是有关数据保护的功能：在存储和传输数据时如何防止对数据进行未经授权的访问或破坏。Application Server 具有基于 J2EE 标准的动态可扩展安全体系结构。内置了多种安全功能，包括密码学、验证和授权以及公共密钥基本结构。Application Server 是基于 Java 安全模型构建的，该安全模型使用沙箱，应用程序可以在沙箱中安全地运行，而不会给系统或用户带来潜在的危险。本节介绍了以下主题：

了解应用程序和系统安全性

从宽泛意义上讲，应用程序安全性有两种：

除了应用程序安全性以外，还有影响 Application Server 系统中所有应用程序的系统安全性。

程序安全性受应用程序开发者的控制，因此本文档不对其进行讨论；声明安全性受应用程序开发者的控制要少一些，本文档中只偶尔涉及到声明安全性。本文档主要针对系统管理员，因此主要讲述了系统安全性。

管理安全性的工具

Application Server 提供了以下用于管理安全性的工具：

Java 2 Platform, Standard Edition (J2SE) 提供了两个用于管理安全性的工具：

有关使用 keytool、policytool 和其他 Java 安全性工具的更多信息，请参见 http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security 上的 Java 2 SDK Tools and Utilities。

在 Enterprise Edition 中，还可以使用两个实现网络安全服务 (NSS) 的工具来管理安全性。有关 NSS 的更多信息，请访问 http://www.mozilla.org/projects/security/pki/nss/。管理安全性的工具包括：

有关使用 certutil、pk12util 和其他 NSS 安全性工具的更多信息，请参见 http://www.mozilla.org/projects/security/pki/nss/tools 上的 NSS Security Tools。

管理密码安全性

在此版本的 Application Server 中，包含特定域的规范的 domain.xml 文件最初以明文形式包含了 Sun Java System Message Queue 代理的密码。domain.xml 文件中包含此密码的元素为 jms-host 元素的 admin-password 属性。由于在安装期间不能更改此密码，因此它不会对安全性产生很大的影响。

不过，您可以使用管理控制台添加用户和资源，并为这些用户和资源指定密码。部分密码将以明文形式写入 domain.xml 文件，例如用于访问数据库的密码。将这些密码以明文形式保存在 domain.xml 文件中可能会破坏安全性。通过执行以下操作步骤，您可以对 domain.xml 中的任何密码进行加密，包括 admin-password 属性或数据库密码。

Procedure加密 domain.xml 中的密码

  1. 在 domain.xml 文件所在的目录（默认情况下，此目录为 domain-dir/config）中，运行以下 asadmin 命令：


    asadmin create-password-alias --user admin alias-name

    例如，


    asadmin create-password-alias --user admin jms-password

    将显示输入密码提示（在本例中为 admin）。有关更多信息，请参阅 create-password-alias、list-password-aliases 和 delete-password-alias 命令的手册页。

  2. 删除并替换 domain.xml 中的密码。使用 asadmin set 命令可以完成此操作。用于此目的的 set 命令的示例如下：


    asadmin set --user admin server.jms-service.jms-host.
default_JMS_host.admin-password=${ALIAS=jms-password}

  3. 重新启动相关域的 Application Server。

保护具有编码密码的文件

某些文件包含需要使用文件系统权限进行保护的编码密码。这些文件包括：

Procedure更改主密码

主密码 (MP) 是全局性的共享密码。它从不用于验证，也从不会在网络上传输。此密码是整体安全性的要塞点；用户可以选择在需要时手动输入此密码，也可以将其隐藏在文件中。它是系统中最敏感的数据。用户可以通过删除此文件强制系统提示输入 MP。更改主密码后，系统会将其重新保存到主密码密钥库中。

  1. 停止域的 Application Server。使用 asadmin change-master-password 命令提示输入旧密码和新密码，然后对所有依赖项重新进行加密。例如，


    asadmin change-master-password>
Please enter the master password>
Please enter the new master password>
Please enter the the new master password again>

  2. 重新启动 Application Server。

    注意 – 注意 –

    此时，不能启动正在运行的服务器实例并且不能重新启动运行服务器实例，除非已更改这些实例所对应的节点代理上的 SMP。如果在更改服务器实例的 SMP 之前重新启动了该服务器实例，它将无法启动。

  3. 一次停止一个节点代理及与其相关的服务器。再次运行 asadmin change-master-password 命令，然后重新启动节点代理及其相关服务器。

  4. 继续对下一个节点代理执行此过程，直到对所有节点代理均已执行此过程。这样就可以完成滚动更改。

Procedure更改管理员密码

管理密码安全性中介绍了如何对管理员密码进行加密。强烈建议您对管理员密码进行加密。如果要在加密管理员密码之前更改管理员密码，请使用 asadmin set 命令。用于此目的的 set 命令的示例如下：


asadmin set --user admin 
server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

还可以使用管理控制台更改管理员密码，步骤如下。

  1. 在管理控制台树组件中，展开“配置”节点。

  2. 选择要配置的实例：

    • 要配置特定的实例，请展开该实例的配置节点。例如，对于默认实例 server，请展开 server-config 节点。

    • 要为所有实例配置默认设置，请展开 default-config 节点。

  3. 展开“安全性”节点。

  4. 展开“区域”节点。

  5. 选择 admin-realm 节点。

  6. 在“编辑区域”页面中，单击“管理用户”按钮。

  7. 选择名为 admin 的用户。

  8. 输入新密码并确认密码。

  9. 单击“保存”以保存新密码，或单击“关闭”以关闭页面而不保存新密码。

指定安全职责

将为以下角色指定安全职责：

应用程序开发者

应用程序开发者负责：

应用程序开发者可以使用 deploytool 等工具来编辑应用程序部署描述符。《The J2EE 1.4 Tutorial》中的 "Security" 一章详细介绍了这些安全性任务，您可以通过以下 URL 查看该教程：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

应用程序部署者

应用程序部署者负责：

应用程序部署者可以使用 deploytool 等工具来编辑应用程序部署描述符。《The J2EE 1.4 Tutorial》中的 "Security" 一章详细介绍了这些安全性任务，您可以通过以下 URL 查看该教程：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

系统管理员

系统管理员负责：

系统管理员使用管理控制台来管理服务器安全性设置，并使用 certutil 来管理证书。本文档主要针对系统管理员。

关于验证和授权

验证和授权是应用程序服务器安全性的核心概念。以下主题讨论了与验证和授权相关的内容：

验证实体

验证是一种实体（用户、应用程序或组件）用来确定另一个实体是否是其声明的实体的方法。实体使用安全凭证对其自身进行验证。凭证可以是一个用户名和密码、一个数字证书或其他凭证。

通常，验证表示用户使用用户名和密码登录到某个应用程序；也可以指 EJB 从服务器请求资源时，提供安全凭证。通常，服务器或应用程序要求客户机进行验证；另外，客户机也可以要求服务器对其自身进行验证。如果验证是双向的，则称为双向验证。

当实体尝试访问受保护的资源时，Application Server 将使用为该资源配置的验证机制来决定是否授予访问权限。例如，用户可以在 Web 浏览器中输入用户名和密码，如果应用程序顺利完成了对那些凭证的检验，则表示该用户已通过验证。在此会话余下的时间内，该用户将始终与这个经过验证的安全身份相关联。

Application Server 支持四种类型的验证，如验证实体所述。应用程序在其部署描述符中指定所使用的验证类型。有关使用 deploytool 来配置应用程序验证方法的更多信息，请参见位于以下 URL 的《The J2EE 1.4 Tutorial》：http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html。

表 9–1 Application Server 验证方法

验证方法 

通信协议 

说明 

用户凭证加密 

基本 

HTTP（SSL 可选） 

使用服务器的内置弹出式登录对话框。 

无，除非使用 SSL。 

基于表单 

HTTP（SSL 可选） 

应用程序提供它自己的自定义登录页面和错误页面。 

无，除非使用 SSL。 

客户机证书 

HTTPS（基于 SSL 的 HTTP） 

服务器使用公共密钥证书来验证客户机。 

SSL 

检验单点登录

单点登录允许一个虚拟服务器实例中的多个应用程序共享用户验证状态。使用单点登录，登录到一个应用程序的用户也会隐式登录到需要相同验证信息的其他应用程序。

单点登录以组为基础。其部署描述符定义了相同的组并使用相同验证方法（基本、表单、摘要或证书）的所有 Web 应用程序共享单点登录。

对于为 Application Server 定义的虚拟服务器，默认情况下已启用单点登录。有关禁用单点登录的信息，请参见配置单点登录 (single sign-on, SSO)。

对用户进行授权

用户通过验证后，授权级别将决定该用户可以执行哪些操作。用户的授权以其角色为基础。例如，人力资源应用程序可以授权管理者查看所有雇员的个人信息，但只允许雇员查看自己的个人信息。有关角色的更多信息，请参见了解用户、组、角色和区域。

指定 JACC 提供者

JACC（Java 容器授权合同）属于 J2EE 1.4 规范，它为可插拔授权提供者定义了接口。这使得管理员可以设置第三方插件模块来执行授权。

默认情况下，Application Server 提供一个符合 JACC 规范的基于文件的简单授权引擎。还可以指定其他第三方 JACC 提供者。

JACC 提供者使用 Java 验证和授权服务 (JAAS) API。JAAS 允许服务验证并强制对用户进行访问控制。JAAS 实现了 Java 技术版本的标准可插拔验证模块 (PAM) 框架。

审计验证和授权决策

Application Server 可以通过审计模块提供对所有验证和授权决策的审计跟踪。Application Server 提供了一个默认的审计模块，还提供了自定义审计模块的功能。有关开发自定义审计模块的信息，请参见 Application Server Developer's Guide。

配置消息安全性

消息安全性使服务器可以在消息层执行 Web 服务调用和响应的端对端验证。Application Server 使用 SOAP 层上的消息安全性提供者来实现消息安全性。消息安全性提供者提供了请求和响应消息所需的验证类型等信息。支持的验证类型包括：

该版本附带了两个消息安全性提供者。可以为 SOAP 层的验证配置消息安全性提供者。可以配置的提供者包括 ClientProvider 和 ServerProvider。

对消息层安全性的支持以（可插入）验证模块的形式集成到 Application Server 及其客户机容器中。默认情况下，Application Server 中的消息层安全性处于禁用状态。

可以为整个 Application Server 或者为特定应用程序或方法配置消息层安全性。第 10 章，配置消息安全性介绍了如何配置 Application Server 级别的消息安全性。Developer' s Guide 的 "Securing Applications" 一章介绍了如何配置应用程序级别的消息安全性。

了解用户、组、角色和区域

Application Server 对以下实体强制执行其验证和授权策略：

注 –

尽管用户和组是为整个 Application Server 指定的，但是每个应用程序都需要定义自己的角色。当封装和部署应用程序时，应用程序会指定用户/组和角色之间的映射，如下图所示。

图 9–1 角色映射

该图显示了如何将用户指定到组中、如何将用户和组指定给角色以及应用程序如何使用组和角色。

用户

用户是已在 Application Server 中定义的单个（或应用程序）身份。用户可以与组关联。Application Server 验证服务可以管理多个领域中的用户。

组

J2EE 组（或简称组）是按常见特性（例如职务或用户配置文件）分类的用户类别。例如，假定电子商务应用程序的用户属于 customer 组，但是大客户可以属于 preferred 组。将用户分组可以简化对用户量很大时的访问控制。

角色

角色定义用户可以访问哪些应用程序和每个应用程序的哪些部分，并定义用户可以执行的操作。也就是说，角色决定用户的授权级别。

例如，假定在人事应用程序中，所有雇员均可以访问电话号码和电子邮件地址，但只有管理人员才能访问薪水信息。该应用程序至少需要定义两个角色：employee 和 manager；仅允许 manager 角色中的用户查看薪水信息。

角色与用户组的不同之处在于，角色在应用程序中定义功能，而用户组是以某一方式相关的一组用户。例如，假定在人事应用程序中有 full-time、part-time 和 on-leave 几个组，但所有这些组中的用户仍是 employee 角色。

角色是在应用程序部署描述符中定义的。相反，组是针对整个服务器和区域而定义的。应用程序开发者或部署者在每个应用程序的部署描述符中将角色映射到一个或多个组。

区域

领域也称为安全策略域或安全域，是服务器定义和强制执行通用安全策略的范围。在实际应用中，区域是服务器存储用户和组信息的系统信息库。

Application Server 预先配置了三个领域：file（初始默认领域）、certificate 和 admin-realm。还可以设置 ldap、solaris 或自定义领域。应用程序可以在其部署描述符中指定要使用的区域。如果应用程序不指定领域，Application Server 将使用其默认领域。

在 file 领域中，服务器将用户凭证存储在本地名为 keyfile 的文件中。您可以使用管理控制台来管理 file 领域中的用户。有关更多信息，请参见管理 file 区域用户。

在 certificate 领域中，服务器将用户凭证存储在证书数据库中。使用 certificate 领域时，服务器结合使用证书和 HTTPS 协议来验证 Web 客户机。有关证书的更多信息，请参见证书和 SSL 简介。

admin-realm 也是一个 FileRealm，它将管理员用户凭证存储在本地名为 admin-keyfile 的文件中。您可以使用管理控制台管理此领域中的用户，方法与管理 file 领域中的用户相同。有关更多信息，请参见管理 file 区域用户。

在 ldap 领域中，服务器将从轻量目录访问协议 (Lightweight Directory Access Protocol, LDAP) 服务器（例如 Sun Java System Directory Server）中获取用户凭证。LDAP 是一种协议，它使任何人都可以在网络（无论是公共 Internet 还是企业内联网）中查找组织、个人和其他资源（例如文件和设备）。有关管理 ldap 领域中的用户和组的信息，请参阅您的 LDAP 服务器文档。

在 solaris 领域中，服务器将从 Solaris 操作系统中获取用户凭证。Solaris 9 OS 和更高版本支持此区域。有关管理 solaris 领域中的用户和组的信息，请参阅您的 Solaris 文档。

自定义区域是用户凭证的任何其他系统信息库，例如关系型数据库或第三方组件。有关更多信息，请参见创建自定义区域。

证书和 SSL 简介

本节包括以下主题：

关于数字证书

数字证书（或简称证书）是在 Internet 上唯一地标识人员和资源的电子文件。证书使两个实体之间能够进行安全、保密的通信。

证书有很多种类型，例如个人证书（由个人使用）和服务器证书（用于通过安全套接字层 [SSL] 技术在服务器和客户机之间建立安全会话）。有关 SSL 的更多信息，请参见关于安全套接字层。

证书是基于公共密钥加密的，公共密钥加密使用数字密钥对（很长的数字）对信息进行加密或编码，从而使信息只能被目标收件人读取。然后，收件人对信息进行解密（解码）即可读取该信息。

一个密钥对包含一个公共密钥和一个专用密钥。拥有者对公共密钥进行分发并使任何人都可以使用该公共密钥。但是拥有者永远不会分发专用密钥；专用密钥始终是保密的。由于密钥与数学相关，因此使用了密钥对中的一个密钥进行加密的数据只能通过密钥对中的另一个密钥进行解密。

证书就好像一本护照：它可以标识持有者并提供其他重要信息。证书由称为证书授权机构 (Certification Authority, CA) 的可信赖第三方发布。CA 类似于护照申领办公室：它将验证证书持有者的身份并对证书进行签名，以使他人无法伪造或篡改证书。CA 对证书进行签名之后，持有者可以提供该证书作为身份证明并建立经过加密的保密通信。

最重要的是，证书会将拥有者的公共密钥绑定到拥有者的标识。与护照将照片绑定到其持有者的个人信息类似，证书将公共密钥绑定到有关其拥有者的信息。

除了公共密钥以外，证书通常还包括以下信息：

数字证书受 X.509 格式的技术规范约束。要检验 certificate 领域中某个用户的身份，验证服务将使用 X.509 证书的通用名称字段作为主体名称来检验 X.509 证书。

关于证书链

Web 浏览器已预先配置了一组浏览器自动信任的根 CA 证书。来自其他证书授权机构的所有证书都必须附带证书链，以检验这些证书的有效性。证书链是由一系列 CA 证书发出的证书序列，最终以根 CA 证书结束。

证书最初生成时是一个自签名证书。自签名证书是其签发者（签名者）与主题（其公共密钥由该证书进行验证的实体）相同的证书。如果拥有者向 CA 发送证书签名请求 (CSR)，然后输入响应，自签名证书将被证书链替换。链的底部是由 CA 发布的、用于验证主题的公共密钥的证书（回复）。链中的下一个证书是验证 CA 的公共密钥的证书。通常，这是一个自签名证书（即，来自 CA、用于验证其自身的公共密钥的证书）并且是链中的最后一个证书。

在其他情况下，CA 可能会返回一个证书链。在此情况下，链的底部证书是相同的（由 CA 签发的证书，用于验证密钥条目的公共密钥），但是链中的第二个证书是由其他 CA 签发的证书，用于验证您向其发送了 CSR 的 CA 的公共密钥。然后，链中的下一个证书是用于验证第二个 CA 的密钥的证书，依此类推，直至到达自签名的根证书。因此，链中的每个证书（第一个证书之后的证书）都需要验证链中前一个证书的签名者的公共密钥。

关于安全套接字层

安全套接字层 (Secure Socket Layer, SSL) 是用来确保 Internet 通信和事务安全的最常见的标准。Web 应用程序使用 HTTPS（基于 SSL 的 HTTP），HTTPS 使用数字证书来确保在服务器和客户机之间进行安全、保密的通信。在 SSL 连接中，客户机和服务器在发送数据之前都要对数据进行加密，然后由收件人对其进行解密。

当 Web 浏览器（客户机）需要与某个安全站点建立连接时，则会发生 SSL 握手：

握手之后，即表示客户机已检验了 Web 站点的身份，并且只有该客户机和 Web 服务器拥有会话密钥副本。从现在开始，客户机和服务器便可以使用该会话密钥对彼此间的所有通信进行加密。这样就确保了客户机和服务器之间的通信的安全性。

SSL 标准的最新版本称为 TLS（传输层安全性）。Application Server 支持安全套接字层 (Secure Socket Layer, SSL) 3.0 和传输层安全性 (Transport Layer Security, TLS) 1.0 加密协议。

要使用 SSL，Application Server 必须拥有接受安全连接的每个外部接口或 IP 地址的证书。只有安装了数字证书之后，大多数 Web 服务器的 HTTPS 服务才能够运行。使用使用 keytool 实用程序生成证书中介绍的过程来设置您的 Web 服务器可用于 SSL 的数字证书。

关于加密算法

加密算法用于加密或解密。SSL 和 TLS 协议支持用于服务器和客户机彼此进行验证、传输证书和建立会话密钥的各种加密算法。

某些加密算法比其他加密算法更强大且更安全。客户机和服务器可以支持不同的加密算法套件。从 SSL3 和 TLS 协议中选择加密算法。在安全连接期间，客户机和服务器同意在通信中使用它们均已启用的最强大的加密算法，因此通常需要启用所有加密算法。

使用基于名称的虚拟主机

对安全应用程序使用基于名称的虚拟主机可能会带来问题。这是 SSL 协议本身的设计限制。必须先进行 SSL 握手（客户机浏览器在这时接受服务器证书），然后才能访问 HTTP 请求。这样，在验证之前就无法确定包含虚拟主机名的请求信息，因此也不能将多个证书指定给单个 IP 地址。

如果单个 IP 地址上的所有虚拟主机都需要通过同一证书的验证，则添加多个虚拟主机将不会影响服务器上正常的 SSL 操作。但是请注意，大多数浏览器会将服务器的域名与证书中列出的域名（如果有的话，也主要适用于官方的 CA 签名证书）进行比较。如果域名不匹配，这些浏览器将显示警告。通常在生产环境中，只将基于地址的虚拟主机与 SSL 一起使用。

关于防火墙

防火墙控制两个或多个网络之间的数据流，并管理网络之间的链接。防火墙可以包含硬件和软件元素。本节介绍了一些常用的防火墙体系结构及其配置。此处的信息主要是针对 Application Server 的。有关特定防火墙技术的详细信息，请参阅防火墙供应商提供的文档。

通常，需要对防火墙进行配置，以便客户机访问所需的 TCP/IP 端口。例如，如果 HTTP 侦听器正在端口 8080 上运行，则将防火墙配置为仅允许处理端口 8080 上的 HTTP 请求。同样地，如果为端口 8181 设置了 HTTPS 请求，则必须将防火墙配置为允许处理端口 8181 上的 HTTPS 请求。

如果需要通过 Internet 对 EJB 模块进行直接的 RMI-IIOP 访问，RMI-IIOP 全称为 Remote Method Invocations over Internet Inter-ORB Protocol（通过基于 Internet 的 ORB 间协议的远程方法调用），则还需要打开 RMI-IIOP 侦听器端口，但强烈建议您不要这样做，因为这样可能会破坏安全性。

在双防火墙体系结构中，您必须将外部防火墙配置为允许处理 HTTP 和 HTTPS 事务。您必须将内部防火墙配置为允许 HTTP 服务器插件与防火墙后面的 Application Server 进行通信。

使用管理控制台管理安全性

管理控制台提供了对安全性的以下方面进行管理的方法：

服务器安全性设置

在“安全性设置”页面中，设置整个服务器的属性，包括指定默认区域、匿名角色和默认的主体用户名和密码。有关更多信息，请参见配置安全性设置。

区域和 file 区域用户

了解用户、组、角色和区域中介绍了领域的概念。

有关这些任务的详细信息，请参见有关领域的管理控制台任务。

JACC 提供者

指定 JACC 提供者中介绍了 JACC 提供者。使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见有关 JACC 提供者的管理控制台任务。

审计模块

审计验证和授权决策中介绍了审计模块。审计是记录重要事件（例如错误或安全漏洞）以便随后进行检查的方法。所有验证事件都被记录到 Application Server 日志中。完整的访问日志提供了 Application Server 访问事件的顺序线索。

使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见有关审计模块的管理控制台任务。

消息安全性

配置消息安全性中介绍了消息安全性的概念。使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见第 10 章，配置消息安全性。

HTTP 和 IIOP 侦听器安全性

HTTP 服务中的每个虚拟服务器都通过一个或多个 HTTP 侦听器提供网络连接。有关 HTTP 服务和 HTTP 侦听器的一般信息，请参见什么是 HTTP 服务？。

Application Server 支持 CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）对象，这类对象使用基于 Internet 对象请求代理间协议 (Internet Inter-Orb Protocol, IIOP) 在网络上进行通信。IIOP 侦听器接受来自 EJB 组件的远程客户机和其他基于 CORBA 的客户机的外来连接。有关 IIOP 侦听器的一般信息，请参见IIOP 侦听器。

使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见有关侦听器和 JMX 连接器的管理控制台任务。

管理服务安全性

管理服务确定服务器实例是一个常规实例、一个域管理服务器 (DAS) 还是一个组合。使用管理服务配置 JSR-160 兼容的远程 JMX 连接器，该连接器为远程服务器实例处理域管理服务器与节点代理（管理主机上的服务器实例）之间的通信。

使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见配置管理服务的 JMX 连接器的安全性。

安全映射

关于安全映射中介绍了连接器连接池的安全映射的概念。使用管理控制台可以执行以下任务：

有关这些任务的详细信息，请参见有关连接器连接池的管理控制台任务。