|
|
以下部分描述与 WebLogic Server 中的安全有关的安全基础：
通过审核过程，可以收集、存储和分发有关操作请求及其请求结果的信息（出于非否认目的）。换句话说，审核提供对计算机活动的电子跟踪。在 WebLogic Server 安全体系结构中，审核提供程序用于提供审核服务。
经过配置后，当更改域配置或调用域中任何资源管理操作时，WebLogic 安全框架会在执行安全操作（例如，身份验证或授权）前后调用审核提供程序。由审核提供程序自行做出审核特定事件的决定，该决定可以基于特定审核条件和/或严重程度级别。可以将包含审核信息的记录写入输出仓库（如 LDAP 服务器、数据库和简单文件）。
身份验证是一种机制，调用者用其证明自己正在代表特定用户或系统进行操作。身份验证使用凭据（如用户名/密码的组合）来响应“您是谁？”这一问题。
在 WebLogic Server 中，身份验证提供程序用于证明用户或系统进程的标识。身份验证提供程序还可以记忆、传输标识信息，并在需要时将标识信息用于系统的各种组件（通过主题）。在身份验证过程中，通过签署并验证委托人的真实性，委托人验证提供程序可为包含在主题中的委托人（用户或组）提供附加安全保护。
委托人是作为身份验证的结果指定给用户或组的一个标识。用户和组都可以被应用服务器（如 WebLogic Server）用作委托人。Java 身份验证和授权服务（Java Authentication and Authorization Service，简称 JAAS）要求将“主题”作为身份验证信息的容器，包括委托人。
图 3-1 说明用户、组、委托人和主题之间的关系。
作为成功进行身份验证的一部分，将签署委托人并将其存储在主题中，以便将来使用。委托人验证提供程序签署委托人，而身份验证提供程序的 LoginModule 则将委托人实际存储在主题中。随后，当调用者试图访问存储在主题中的委托人时，委托人验证提供程序将验证自签署该委托人以来是否被修改过，然后将委托人返回给调用者（假定符合所有其他安全条件）。
任何要代表 WebLogic Server 用户或组的委托人都需要实现 WLSUser 和 WLSGroup 接口，这些接口包含在 weblogic.security.spi 包中。
无论客户端是应用程序、Applet、Enterprise JavaBean (EJB) 还是需要身份验证的 Servlet，WebLogic Server 都可使用 Java 身份验证和授权服务 (JAAS) 类对客户端进行可靠安全的身份验证。JAAS 实现了 Java 版的可插入身份验证模块（Pluggable Authentication Module，简称 PAM）框架，该框架允许应用程序保持独立于底层身份验证技术。因此，使用 PAM 框架可以使用新的或更新后的身份验证技术，而无需对应用程序进行修改。
WebLogic Server 使用 JAAS 对远程胖客户端进行身份验证，在内部用于身份验证。因此，只有自定义身份验证提供程序的开发人员和远程胖客户端应用程序的开发人员必须与JAAS 直接相关。瘦客户端的用户或容器包含的胖客户端应用程序（例如，从 Servlet 上调用 Enterprise JavaBean (EJB) 的应用程序）的开发人员不需要直接使用 JAAS 或掌握 JAAS 知识。
LoginModule 是进行身份验证的工具：所有 LoginModule 都负责在安全领域内对用户进行身份验证，并负责使用必要的委托人（用户/组）填充主题。不用于边界身份验证的 LoginModule 也可以验证提交的证明材料（例如，用户密码）。
如果在安全领域中配置有多个身份验证提供程序，则每个身份验证提供程序的 LoginModule 都会将委托人存储在同一主题中。因此，如果通过一个身份验证提供程序的 LoginModule 将一个名为“Joe”的 WebLogic Server 用户（即 WLSUser 接口的实现）的委托人添加到主题中，则安全领域中的任何其他身份验证提供程序遇到“Joe”时都应引用同一个人。换句话说，其他身份验证提供程序的 LoginModule 不能向表示 WebLogic Server 用户（例如，名为“Joseph”）的主题添加另一个委托人来引用同一个人。但是，允许另一个身份验证提供程序的 LoginModule 添加非 WLSUser 类型、名为“Joseph”的委托人。
如果安全领域配置有多个身份验证提供程序，则验证器提供程序上的“控制标志”特性将决定身份验证提供程序的执行顺序。“控制标志”特性的值如下：
CallbackHandler 是一种高度灵活的 JAAS 标准，允许将不定数量的参数作为复杂对象传递给方法。有三种类型的 CallbackHandler：NameCallback、PasswordCallback 和 TextInputCallback，它们都是 javax.security.auth.callback 包的一部分。NameCallback 和 PasswordCallback 分别返回用户名和密码。TextInputCallback 可用于访问用户在登录表单上输入到任何附加字段（即获取用户名和密码的字段以外的字段）中的数据。在使用时，每个附加表单字段都应该有一个 TextInputCallback，而每个 TextInputCallback 的提示字符串都必须与表单中的字段名匹配。WebLogic Server 仅将 TextInputCallback 用于登录基于表单的 Web 应用程序。
应用程序实现 CallbackHandler 并将其传递给底层安全服务，以便它们可以与应用程序进行交互，检索特定的身份验证数据（如用户名和密码），或者显示某些信息（如错误和警告消息）。
CallbackHandlers 以一种依赖于应用程序的方式实现。例如，带图形用户界面 (GUI) 的应用程序实现会弹出窗口提示所请求的信息或显示错误消息。实现也可以选择在未询问用户的情况下从备用源获取请求的信息。
底层安全服务通过向 CallbackHandler 传递单个 Callbacks来请求不同类型的信息。CallbackHandler 实现根据传递给它的Callbacks 决定如何检索和显示信息。例如，如果底层服务需要用户名和密码对用户进行身份验证，则使用 NameCallback 和 PasswordCallback。CallbackHandler 可以选择先后提示用户输入用户名和密码，或者在单独窗口中提示用户输入用户名和密码。
使用相互身份验证，要求客户端和服务器相互之间都对自身进行身份验证。这可以使用证书或其他格式的证明材料来完成。WebLogic Server 支持双向 SSL 身份验证，这是相互身份验证的一种形式。但是，根据严格的定义，相互身份验证发生在协议堆栈的更高层，然后进行 SSL 身份验证。有关详细信息，请参阅单向/双向 SSL 身份验证。
使用 LoginModule 时，标识声明提供程序支持单一登录。例如，标识声明提供程序可以处理 SAML 声明，这样就可以避免要求用户多次登录。
与简单身份验证情况不同，标识声明提供程序使用的 LoginModule 不验证证明材料，如用户名和密码；它们只验证用户是否存在。
标识声明提供程序支持用户名映射器，该映射器可以将一个有效的标记映射到一个 WebLogic Server 用户。开发标识声明提供程序以支持特定类型的标记，这些标记将用于声明用户或系统进程的标识。可以开发一个标识声明提供程序以支持多个标记类型，但 WebLogic Server 管理员必须配置标识声明提供程序，以便它只对一个“活动”标记类型进行验证。您可以在一个安全领域中配置多个具有验证相同标记类型功能的标识声明提供程序，但是只有一个标识声明提供程序实际执行此验证。
| 注意： | 要对 X.501 和 X.509 证书使用 WebLogic 标识声明提供程序，可以选择使用 WebLogic Server 产品 (weblogic.security.providers.authentication.DefaultUserNameMapperImpl) 附带的默认用户名映射器或者提供自己的 weblogic.security.providers.authentication.UserNameMapper 接口实现。有关详细信息，请参阅
是否需要开发自定义标识声明提供程序？（位于“开发 WebLogic Server 的安全提供程序”）。 |
质询标识声明方案提供多个质询、响应消息和状态。WebLogic Server 安全领域包括支持身份验证协议的安全提供程序，这些协议包括 Microsoft 的 Windows NT 质询/响应 (NTLM)、简单且受保护的 GSS-API 协商机制（Simple and Protected GSS-API Negotiation Mechanism，简称 SPNEGO）和其他质询/响应身份验证机制。WebLogic Server 包括一个名为协商标识声明提供程序的 SPNEGO 安全提供程序。可以开发和部署实现 NTLM 或其他质询/响应身份验证机制的安全提供程序。有关详细信息，请参阅开发 WebLogic Server 的安全提供程序。
按照 Java Servlet API 2.3 规范的定义，筛选器是可以修改请求或响应的对象。筛选器在请求到达 Servlet 之前作为请求的预处理器，并且/或者在响应离开 Servlet 后作为响应的后处理器。筛选器提供在可重用单元中封装循环任务的功能。
筛选器可以替换基于容器的身份验证，但这会对此设计带来以下缺点：
web.xml 文件中定义。应用程序编写（不是由创建 WAR 文件的程序员编写）之后，身份验证机制通常由系统管理员确定。可以在应用程序的生命周期内更改机制，站点中所有（或至少大多数）应用程序都需要这样。
Servlet 身份验证筛选器是对筛选器对象的扩展，它可以通过允许用筛选器代替基于容器的身份验证来克服这些缺点。
JAAS LoginModule（在一个 WebLogic 身份验证提供程序中）可用于自定义登录过程。Servlet 身份验证筛选器启用允许身份验证提供程序控制与客户端的实际对话的 LoginModule 模型。自定义用户数据库的位置、执行登录需要的证明材料类型或者带有组的主题的填充都可以通过 LoginModule 实现。另一方面，重定向到远程站点执行登录、从查询字符串中提取出登录信息以及与浏览器协商登录机制都可以通过 Servlet 身份验证筛选器实现。
每当 WebLogic Server 用户请求访问一个受保护的 WebLogic 资源时，都必须经过身份验证。因此，要求每个用户向 WebLogic Server 提供一个凭据（例如，密码）。WebLogic Server 分发中包括的 WebLogic 身份验证提供程序支持以下类型的身份验证：
WebLogic Server 可以使用作为 WebLogic Server 产品的一部分提供的 WebLogic 身份验证提供程序执行不同类型的身份验证，也可以自定义安全提供程序来执行此操作。有关 WebLogic 身份验证提供程序以及如何配置身份验证的信息，请参阅身份验证过程和“确保 WebLogic Server 安全”中的下列部分：
在用户名/密码身份验证中，系统要求用户输入用户 ID 和密码并将其发送到 WebLogic Server。WebLogic Server 检查此信息，如果可信，则允许访问受保护的 WebLogic 资源。
使用安全套接口层（Secure Sockets Layer，简称 SSL）或超文本传输协议（Hyper-Text Transfer Protocol，简称 HTTPS）可以为用户名/密码身份验证提供附加安全级别。由于 SSL 对客户端和 WebLogic Server 之间传输的数据进行加密，所以用户的用户 ID 和密码是在加密的状态下进行传输。因此，WebLogic Server 可以在不危及用户 ID 和密码保密性的情况下对用户进行身份验证。
在启动 SSL 或 HTTPS 客户端请求时，WebLogic Server 通过向客户端提供其数字证书响应客户端。然后，客户端将验证数字证书并建立 SSL 连接。数字证书是由一个实体（可信证书颁发机构）颁发的，可验证 WebLogic Server 的标识。
也可以使用双向 SSL 身份验证，这是相互身份验证的一种形式。如果使用双向 SSL 身份验证，在启用客户端和服务器之间的连接线程之前，需要二者提供证书。请参阅单向/双向 SSL 身份验证。
| 注意： | 作为 WebLogic Server 产品的一部分提供的 WebLogic 身份验证提供程序支持双向 SSL 身份验证。 |
使用摘要身份验证时，客户端向服务器发出一个未经身份验证的请求，服务器则发送一个带有摘要身份验证质询的响应，表示服务器支持摘要身份验证。客户端生成一个临时值并将此值连同时间戳、摘要和用户名一起发送到服务器。摘要是密码、临时值和时间戳的一个密码散列。此时客户端再次请求资源发送用户名以及密码与临时值组合而成的密码散列。服务器自身生成散列，如果生成的散列与请求的散列匹配，则允许该请求。
摘要身份验证的优点是可以抵御重播攻击。该实现在指定的一段时间内维护所用临时值/时间戳的缓存。拒绝所有时间戳早于指定时间戳的请求，同样会拒绝任何使用与缓存中现有的最近时间戳/临时值对相同的时间戳/临时值对的请求。WebLogic Server 将此缓存存储在数据库中。可以使用命令行选项禁用缓存以提高性能。
边界身份验证是验证应用程序服务器域以外的远程用户标识的过程。
边界身份验证通常由远程用户指定用来执行验证的一个已声明标识和某种形式的相应证明材料（通常是以密码短语的形式，如密码、信用卡号、个人标识号或一些其他形式的个人身份信息）来完成。
身份验证代理，实际确定标识的实体，可以采用多种形式，例如，虚拟个人网络（Virtual Private Network，简称 VPN）、防火墙、企业级身份验证服务或其他一些形式的全局标识服务。每一种这些形式的身份验证代理都有一个共同的特征：它们都执行一个身份验证过程，该过程会产生随后必须提交的工件或“标记”以确定已通过身份验证的用户的有关信息。当前，不同供应商的标记格式各不相同，现在正努力使用 XML 定义一个标准标记格式。另外，特性证书有一个基于数字证书的 X.509 标准的现行标准。但是，即使有了所有这些以后，如果设计的应用程序和构建的应用程序体系结构不支持此概念，企业仍然被强制要求其远程用户对网络中的应用程序重新进行身份验证。
WebLogic Server 的设计目的在于通过支持标识声明将单一登录概念一直扩展到边界（请参阅图 3-2）。作为 WebLogic 安全框架的关键部分，标识声明的概念允许 WebLogic Server 使用由边界身份验证方案提供的身份验证机制来实现此功能，这些方案包括安全声明标记语言（Security Assertion Markup Language，简称 SAML）、简单且受保护的 GSS-API 协商机制 (SPNEGO) 或增强协议，如通用安全互操作性（Common Secure Interoperability，简称 CSI）v2。
对边界身份验证的支持要求使用可支持一个或多个标记格式的标识声明提供程序。可以注册使用多个不同的标识声明提供程序。使用 WebLogic Server 支持的各种协议所提供的机制，将标记作为任何普通业务请求的一部分进行传输。WebLogic Server 接收到请求后，负责协议消息处理的实体将识别消息中标记的存在。此信息用于调用 WebLogic 安全框架，从而调用适当的标识声明提供程序来处理标记的验证。标识声明提供程序实现负责执行任何必要的操作以确定标记的有效性和信任，并通过合理的保证程度来提供用户标识而不需要用户对应用程序重新进行身份验证。
SAML 标准定义了一个用于在 Web 上交换软件实体之间的安全信息的框架。SAML 安全基于声明方和依赖方之间的交互。WebLogic Server 9.2 版支持 SAML 1.1 版。
有关这些概念以及如何将它们应用到 SAML 体系结构中的完整描述，请参阅 Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1。
在 WebLogic Server 中通过以下方式支持 SAML：
单一登录功能要求用户只需登录应用程序一次，便可获得对许多不同应用程序组件的访问权限，即使这些组件可能具有它们自己的身份验证方案。通过单一登录，用户只需使用一个标识就可以安全地登录到所有应用程序、网站和主机会话。WebLogic Server可为下列环境提供单一登录 (SSO)：
有关详细信息，请参阅 Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1。
有关在 WebLogic Server 中如何使用 Web 浏览器和 HTTP 客户端实现 SSO的信息，请参阅 WebLogic Server 充当 SAML 源站点和 Weblogic Server 充当 SAML 目标站点。
带桌面的 SSO 将基于 HTTP 的身份验证与 Windows Active Directory 环境中已经通过身份验证的 Microsoft 客户端结合使用。Windows Active Directory 环境使用 Kerberos 作为其安全协议。Kerberos 提供异构领域的网络身份验证。这意味着已登录到 Windows 域的用户可以访问运行于应用程序服务器上的 Web 应用程序，而且可以使用他们的 Windows Active Directory 凭据向服务器进行身份验证。应用程序服务器可以在任何支持 Kerberos 的平台上运行。
当 Web 服务器接收到来自浏览器的请求时，它可以请求浏览器使用 Kerberos 协议进行自我身份验证。该协议通过 HTTP 执行身份验证，使浏览器（大多数情况下是 Internet Explorer）传递一个委托凭据，以允许 Web 应用程序以用户名义登录随后基于 Kerberos 的服务。
当 HTTP 服务器希望登录 Microsoft 客户端时，它使用 WWW-Authorization:Negotiate头将 401 Unauthorized 响应返回给 HTTP 请求。然后，浏览器联系密钥分发中心（Key Distribution Center，简称 KDC）/票据授予服务（Ticket Granting Service，简称 TGS）以获得服务票据。它为票据请求选择一个特殊的服务委托人名称。然后，将返回的票据包装在 SPNEGO 标记中，编码后使用 HTTP 请求发送回服务器。打开标记，就可以对票据进行身份验证。通过身份验证后，返回与请求的 URL 相对应的页面。
有关如何在 WebLogic Server 使用 Microsoft 客户端实现 SSO 的信息，请参阅桌面 SSO 过程。
授权是控制用户和 WebLogic 资源之间的交互的过程，它基于用户标识或其他信息。换句话说，授权将响应“您可以访问什么？”这一问题。在WebLogic Server 中，授权提供程序用于限制用户和 WebLogic 资源之间的交互以确保完整性、保密性和可用性。
“WebLogic 资源”是用来表示底层 WebLogic Server 实体的结构化对象，可使用安全角色和安全策略防止对资源的未经授权访问。
WebLogic 资源是分层结构的。因此，定义这些安全角色和安全策略的级别由您决定。例如，可以将安全角色和安全策略定义为以下级别：整个企业应用程序 (EAR)；包含多个 EJB 的 Enterprise JavaBean (EJB) JAR；上述 JAR 中的特定的 Enterprise JavaBean (EJB)；或者 EJB 中的单一方法。
| 注意： | 在 WebLogic 类的 Javadocs 中详细说明了每个 WebLogic 资源实现。有关详细信息，请参阅“使用角色和策略确保 WebLogic 资源安全”中的WebLogic 资源的类型。 |
安全策略替换了访问控制列表 (ACL)，并回答了“谁可以访问 WebLogic 资源？”这一问题。定义 WebLogic 资源与一个或多个用户、组或安全角色之间的关联时，将创建一个安全策略。可以根据需要为安全策略定义日期和时间约束。在您向 WebLogic 资源分配一个安全策略之前，该资源没有任何保护。
您可以为任何已定义的 WebLogic 资源（例如，EJB 资源或 JNDI 资源）或某个 WebLogic 资源（EJB 方法或 Web 应用程序中的 Servlet）的特定实例的特性或操作指定安全策略。如果为某一类型的 WebLogic 资源指定了一个安全策略，则该资源的所有新实例都将继承该安全策略。指定给单个资源或特性的安全策略会覆盖指定给 WebLogic 资源类型的安全策略。有关已定义的 WebLogic 资源的列表，请参阅 WebLogic 资源。
安全策略存储在授权提供程序数据库中。默认情况下，已经配置了 WebLogic 授权提供程序并且将安全策略存储在嵌入式 LDAP 服务器中。
要使用用户或组创建安全策略，必须在默认安全领域中配置的授权提供程序的安全提供程序数据库中定义该用户或组。要使用安全角色创建安全策略，必须在默认安全领域中配置的角色映射提供程序的安全提供程序数据库中定义安全角色。默认情况下，在嵌入式 LDAP 服务器的数据库中配置 WebLogic 身份验证提供程序和角色映射提供程序。
默认情况下，在 WebLogic Server 中为 WebLogic 资源定义安全策略。这些安全策略基于安全角色和默认全局组。您也可以选择将用户作为安全策略的基础。BEA 建议将安全角色（而不是用户或组）作为安全策略的基础。通过将安全角色作为安全策略的基础，您可以根据授予用户或组的安全角色管理访问，这是一种更有效的管理方法。有关 WebLogic 资源的默认安全策略列表，请参阅“使用角色和策略确保 WebLogic 资源安全”中的默认根级别安全策略。
ContextHandler 是一种高性能的 WebLogic 类，它从资源容器获取额外的上下文信息和特定于容器的信息，并将信息提供给做出访问或角色映射决策的安全提供程序。ContextHandler 接口为内部 WebLogic 资源容器提供向 WebLogic 安全框架调用传递其他信息的方法，以便安全提供程序能够获取由特定方法的参数所提供信息以外的上下文信息。ContextHandler 实质上是一个名称/值列表，它同样要求安全提供程序知道要查找的名称。（换句话说，使用 ContextHandler 需要 WebLogic 资源容器和安全提供程序之间的密切配合。）ContextHandler 中的每一个名称/值对被称为“上下文元素”，且由 ContextElement 对象表示。
当前，可将 ContextHandler 传递给 WebLogic 安全框架的 WebLogic 资源容器有以下三类：Servlet、EJB 和 Web Service 容器。因此，URL (Web)、EJB 和 Web Service 资源类型有不同的上下文元素，仲裁、标识声明、授权凭据映射和角色映射等提供程序以及身份验证提供程序使用的 LoginModule 可以检查其元素值。AuditContext 接口（在实现安全提供程序以发布审核事件时使用）的实现也可以检查上下文元素的值。
有关特定上下文元素值的详细信息，请参阅“开发 WebLogic Server 的安全提供程序”中的 ContextHandlers 和 WebLogic 资源。
与身份验证提供程序的 LoginModule 一样，访问决策是授权提供程序中实际上回答“是否允许访问？”问题的组件。具体地讲，访问决策需要确定某个主题是否具有在应用程序中使用指定参数对 WebLogic 资源执行指定操作的许可权限。提供此信息后，访问决策用 PERMIT、DENY或 ABSTAIN 作为结果予以响应。
仲裁通过衡量每个授权提供程序的访问决策结果，解决安全领域中配置有多个授权提供程序时可能发生的任何授权冲突。在 WebLogic Server 中，仲裁提供程序用于记录多个访问决策返回的结果，并做出最终的 PERMIT 或 DENY 决策。仲裁提供程序还可以指定，在单个授权提供程序的访问决策返回 ABSTAIN 响应时应该执行什么操作。
私钥、数字证书和可信证书颁发机构证书可以在 WebLogic Server 环境中建立和验证标识和信任。
公钥嵌入到数字证书中。私钥和数字证书提供标识。可信证书颁发机构 (CA) 证书为证书建立信任。证书和证书链需要在建立信任关系前进行验证。
本主题详细说明与标识和信任相关联的概念。有关详细信息，请参阅：
WebLogic Server 使用公钥加密技术进行身份验证。使用公钥加密时，将为一台服务器生成一个公钥和一个私钥。将密钥相关，以便使用公钥加密的数据只能使用相应的私钥解密，反之亦然。私钥受到妥善的保护，确保只有私钥的所有者才能解密用公钥加密的消息。
数字证书是用于通过网络（如 Internet）对委托人和实体的唯一标识进行验证的电子文档。数字证书可将经过可信第三方（也称为证书颁发机构）验证的用户或实体标识安全绑定到特定公钥。公钥和私钥的组合可为数字证书的所有者提供唯一的标识。
数字证书可对特定公钥制定、实际上属于特定用户或实体的声明进行验证。数字证书的接收方可以使用数字证书中的公钥验证数字签名是否通过相应的私钥创建。如果验证成功，此推理链可保证数字证书中指定的主题拥有相应的私钥，并且数字签名由该主题创建。
受到广泛认可的数字证书格式是由 ITU-T X.509 国际标准定义的。任何符合 X.509 标准的应用程序都可以读取或编写数字证书。WebLogic Server 中的公钥基础结构 (PKI) 可识别符合 X.509 版本 3 或 X.509v3 的数字证书。BEA 建议从 Verisign 或 Entrust 等证书颁发机构获得数字证书。
有关详细信息，请参阅“确保 WebLogic Server 安全”中的配置 SSL 。
数字证书由证书颁发机构颁发。任何受信任的、愿意对发布数字证书和公钥的对象的标识提供担保的第三方组织或公司都可以作为证书颁发机构。在证书颁发机构创建数字证书时，证书颁发机构使用其私钥为其签名，以确保可以检测到任何篡改。然后，证书颁发机构将签名的数字证书返回给请求方。
请求方可使用证书颁发机构的公钥验证证书颁发机构的签名。证书颁发机构通过提供一个由高级证书颁发机构（可证明低级别证书颁发机构的公钥有效性）颁发的证书，使其公钥可用。此方案产生了证书颁发机构的层次。顶级自签名证书（称为根证书）的层次最高 ，因为它不再需要其他公钥来证明。根证书由可信（根）证书颁发机构颁发。
如果接收方有一个包含证书颁发机构公钥（由接收方信任的高级证书颁发机构签名）的数字证书，加密消息的接收方可以用递归的方式在证书颁发机构公钥中建立信任。从这种意义上来说，数字证书是一种实现数字信任的方法。最后，只需信任少数顶级的证书颁发机构的公钥。通过一个证书链，可以建立对大量用户的数字签名的信任。
因此，数字签名可确定通信实体的标识，但数字签名的受信任程度与用来验证它的公钥受信任的程度相同。
有关详细信息，请参阅“确保 WebLogic Server 安全”中的配置 SSL 。
依赖公钥技术实现安全的应用程序必须确信用户公钥的真实性。用户可能有一个证书链，它以递归的方式指向发布初始证书（称为结束证书）的可信 CA。在使用证书链建立信任前，必须验证证书链。另外，用户可能没有从可信 CA 到目标证书的完整链。公钥技术的另一项要求就是完成一个从目标证书到可信 CA 的有效证书链。
在 WebLogic Server 中，由证书查找和验证（Certificate Lookup and Validation，简称 CLV）框架执行证书验证，该框架可完成并验证入站双向 SSL、出站 SSL、应用程序代码和 WebLogic Web Service 的 X509 证书链。CLV 框架收到一个证书或证书链，完成该链（如有必要），然后查找并验证证书链中的证书。该框架可以使用结束证书、主题 DN、发行方 DN 及序列号和/或主题关键字标识符查找并验证证书链。另外，框架还可以对证书链执行附加验证，如撤销检查。
CLV 框架基于 JDK 体系结构和插件框架，用于定位和验证证书链。CLV 提供程序是使用 JDK 证书路径生成器和证书路径验证器 API/SPI 创建的。
通过使用 SSL，可以确保通过 Web 连接的应用程序之间通信的安全。有关 SSL 通信组件的讨论以及为什么每个组件都是必要的，请参阅 Netscape Communications Corporation 发布的 How SSL Works。
本版本 WebLogic Server 使用 Certicom SSLPlus Java 4.0 版 SSL 实现。RSA Cert-J 和 Crypto-J 已升级到 Cert-J 2.1.1 版和 Crypto-J 3.5 版。
WebLogic Server 完全支持 SSL 通信。默认情况下，将 WebLogic Server 配置为单向 SSL 身份验证，但是要禁用 SSL 端口。通过使用管理控制台，可以将 WebLogic Server 配置为双向 SSL 身份验证。
要为您的服务器获取数字证书，请您生成一个公钥、私钥以及一个包含您的公钥的证书签名请求 (CSR)。发送 CSR 请求到证书颁发机构，然后按照获取已签名数字证书的过程进行操作。
有了私钥、数字证书以及其他所需的可信 CA 证书后，您需要存储它们以便 WebLogic Server 可以使用它们验证标识。将私钥和证书存储在密钥库中。
| 注意： | 为了向后兼容，还可以将私钥和证书存储在文件中。有关私钥、公钥、证书要求和步骤的详细信息，请参阅配置 SSL 和“确保 WebLogic Server 安全”。 |
要在使用浏览器连接到 WebLogic 服务器时使用 SSL，您只需在 URL 中指定 HTTPS 和安全端口（端口号 7002）。例如：
|
其中 localhost 是指承载 Web 应用程序的系统的名称。
WebLogic Server 提供对 SSL 的纯 Java 实现。SSL 通常提供：
使用 SSL 时，目标（服务器）总是自己对发起方（客户端）进行身份验证。（可选）如果目标请求身份验证，则发起方也可以自己对目标进行身份验证。加密可以使通过网络传输的数据只被预定接收方识别。SSL 连接从一个握手开始，在握手期间，应用程序交换数字证书，就将使用的加密算法达成一致，并生成会话的剩余时间里要使用的加密密钥。
如果您正在使用 Web 浏览器与 WebLogic Server 通信，可以使用带 SSL (HTTPS) 的超文本传输协议来确保网络通信的安全。
WebLogic Server 通过 SSL 以隧道的方式使用 HTTP、T3 和 IIOP 协议。Web 浏览器和 Java 客户端可以按下列方式使用 SSL：
https 与服务器进行 SSL 连接。然后，浏览器通过此 SSL 连接发送 HTTP 请求并接收 HTTP 响应。例如：
https://myserver.com/mypage.html
WebLogic Server 支持 SSL 版本控制，这意味着它可以通过此协议（包括 Web 浏览器）与任何客户端进行通信。
t3s://myserver.com:7002/mypage.html
在 WebLogic Server 中运行的 Java 客户端既可以与其他 WebLogic Server 建立 T3S 连接，也可以与其他支持 SSL 的服务器（如 Web 服务器或安全代理服务器）建立 HTTPS 连接。
WebLogic Server 支持单向和双向 SSL 身份验证。使用单向 SSL 身份验证，要求目标（服务器）向发起方（客户端）提供数字证书以证明其标识。客户端执行以下两项检查来验证数字证书：
使用双向 SSL 身份验证，在启用客户端和服务器之间的 SSL 连接之前，需要二者出具数字证书。因此，在这种情况下，WebLogic Server 不仅对客户端进行自身的身份验证（这是证书身份验证的最低要求），而且还要求从请求客户端进行身份验证。当您必须限制仅访问可信客户端时，双向 SSL 身份验证非常有用。
图 3-3 说明 WebLogic Server SSL 连接并显示哪些连接支持单向 SSL、双向 SSL 还是同时支持两者。Web 浏览器客户端、Web Server、胖客户端、Web Service 客户端和 SSL 服务器连接都可以配置为单向或双向 SSL。WebLogic Server 确定是将 SSL 连接配置为单向还是双向。使用管理控制台配置 SSL。
主机名验证是对进行 SSL 连接的主机的名称是否是预期方或授权方进行验证的过程。当 Web 客户端（Web 浏览器、WebLogic 客户端或充当客户端的 WebLogic Server）请求建立一个与另一个应用程序服务器的 SSL 连接时，主机名验证可防止中间人攻击。
默认情况下，SSL 客户端，作为 SSL 握手的一个功能，会将 SSL 服务器的数字证书的 SubjectDN 中的公用名称与试图连接的 SSL 服务器主机名进行比较。如果这些名称不匹配，则删除此 SSL 连接。
信任管理器提供了一种覆盖默认 SSL 信任验证规则的方法。它允许服务器决定是否信任正与其联系的客户端。使用信任管理器，可以在继续进行 SSL 连接之前执行自定义检查。例如，您可以使用信任管理器指定只有来自特定位置（如城镇、省或国家/地区）的用户或带有其他特殊特性的用户可以获得通过 SSL 连接进行访问的权限。
WebLogic Server 提供了 weblogic.security.SSL.TrustManager 接口。该接口允许在 SSL 握手期间调用自定义信任管理器实现。自定义实现可以覆盖由 SSL 实现验证检查检测到的握手错误，或者基于自己的证书规则引发错误。
WebLogic Server 还提供了 weblogic.security.SSL.CertPath.TrustManager 接口，应用程序和自定义代码可以使用它控制出站 SSL 是否使用证书查找和验证。
| 注意： | 此接口替换了 weblogic.security.SSL.TrustManagerJSSE 接口（不赞成在本版本 WebLogic Server 中使用该接口）。 |
非对称密钥（也可称为公钥）算法通过一对相异但数学上相关的密钥实现：公钥和私钥。
WebLogic Server 中的公钥基础结构（Public Key Infrastructure，简称 PKI）也支持数字签名算法。数字签名算法只是用于生成数字签名的公钥算法。
WebLogic Server 支持 Rivest、Shamir 和 Adelman (RSA) 算法。
使用对称密钥算法时，可以用相同的密钥加密和解密消息。这个常用的密钥加密系统使用一个对称的密钥算法对两个通信实体间发送的消息进行加密。与非对称密码系统相比，对称密码系统相对较快。
块密码是一种对称密钥算法，可以将固定长度的纯文本（未加密文本）数据块转换为相同长度的加密文本（已加密文本）数据块。根据随机生成的会话密钥值发生此转换。该固定长度即是块大小。
WebLogic Server 中的 PKI 支持下列对称密钥算法：
DES-CBC 是运行在密码块链接（Cipher Block Chaining，简称 CBC）模式下的 64 位块密码。它提供 56 位密钥。（从全部 64 位密钥中分离出 8 位校验位。）
双密钥三重 DES 是运行在“加密-解密-加密”（Encrypt-Decrypt-Encrypt，简称 EDE）模式下的 128 位块密码。双密钥三重 DES 提供两个 56 位密钥（实际上相当于一个 112 位密钥）。
一段时间以来，使用三重 DES 保护或传输 DES 加密密钥已经成为通用的做法，这就意味着要对输入数据（在此情况下为单一 DES 密钥）进行加密、解密然后再加密（一个加密-解密-加密的过程）。两个加密操作使用相同的密钥。
| 注意： | WebLogic Server 用户不能扩展或修改此算法列表。 |
WebLogic Server 支持 MD5 和 SHA（Secure Hash Algorithm，安全散列算法）消息摘要算法。MD5 和 SHA 都是大家熟知的单向散列算法。单向散列算法获取一条消息并将其转换成固定位数的数字串，也称为消息摘要或散列值。
MD5 是一种 128 位的高速散列，可用于 32 位计算机。虽然 SHA 使用 160 位散列可提供更高的安全性，但其速度比 MD5 慢。
密码组是一种 SSL 加密方法，包括密钥交换算法、对称加密算法和安全散列算法。密码组用于保护通信的完整性。例如，名为 RSA_WITH_RC4_128_MD5 的密码组使用 RSA 进行密钥交换，使用带 128 位密钥的 RC4 进行批量加密，使用 MD5 进行消息摘要。
检查 http://csrc.nist.gov/cryptval/ 中的验证列表，查看 FIPS140 验证状态。
WebLogic Server 支持表 3-1 中的 RSA 密码组。
防火墙可以限制两个网络之间的流量。防火墙可以是软件和硬件的组合，包括路由器和专用网关计算机。它们采用筛选器根据协议、请求的服务、路由信息以及源主机和目标主机或源网络和目标网络，允许或禁止流量通过。它们还允许通过身份验证的用户访问。
图 3-4 用一个对流向 WebLogic Server 群集的流量进行筛选的防火墙来说明防火墙的典型设置。
在 WebLogic Server 中，您可以结合防火墙使用下列功能：
您可以使用 WebLogic Server 连接筛选器设置防火墙，以根据协议、IP 地址和 DNS 节点名筛选网络流量。有关详细信息，请参阅“WebLogic 安全性编程”中的使用网络连接筛选器。
您可以使用标识声明提供程序来设置“边界身份验证”- 一种使用标记的特殊类型的身份验证。WebLogic Server 安全体系结构支持执行基于边界的身份验证（Web 服务器、防火墙、VPN）和处理多个安全标记类型/协议（SOAP、SAML、SPNEGO、IIOP-CSIv2）的标识声明提供程序。
对于用户身份验证和授权的实现和使用，BEA WebLogic Server 使用 SDK 版本 J2SE 5.0 的安全服务。与其他 J2EE 组件一样，安全服务以标准化、模块化的组件为基础。BEA WebLogic Server 根据标准来实现这些 Java 安全服务方法，并添加自动处理许多应用程序行为细节的扩展，而无需额外编程。
BEA WebLogic Server 支持 J2SE 5.0 安全，这意味着应用程序开发人员可以使用 Sun Microsystems 在安全领域的最新增强和开发，从而充分利用公司在 Java 编程专门技术方面的投资。通过遵循已定义和文档化的 Java 标准，WebLogic Server 的安全支持对 Java 开发人员来说有一条通同基准线。WebLogic Server 提供的创新都建立在 J2SE 5.0 基线支持的基础上。
WebLogic Server适应并支持下列 J2SE 5.0 安全包：
JSSE 是一组支持和实现 SSL 和 TLS v1 协议的包，使得这些协议和功能能够通过编程的方式使用。WebLogic Server 支持安全套接口层 (SSL)，可用于对通过 WebLogic Server 客户端和其他服务器传送的数据。
当 JSSE 为 SSL 功能提供一组核心类时，其他公司（如 Certicom）提供对这些类的扩展。WebLogic Server 在实现 SSL 中使用了 Certicom JSSE 扩展。
JAAS 是一组包，为基于用户的身份验证和访问控制提供一个框架。BEA WebLogic Server 仅使用 JAAS 的身份验证类。
有关 JAAS 的详细信息，请参阅 Java 身份验证和授权服务 (JAAS)。
Java 安全管理器由 Sun Microsystems, Inc. 开发，是 Java 虚拟机 (JVM) 的安全管理器。安全管理器与 Java API 一起工作，通过 java.lang.SecurityManager 类定义安全边界。通过 SecurityManager 类，程序员能够为其 Java 应用程序建立自定义安全策略。
可以将 Java 安全管理器与 WebLogic Server 结合使用，为 JVM 中运行的 WebLogic 资源提供附加保护。使用 Java 安全管理器保护 WebLogic Server 中的 WebLogic 资源是一个可选安全步骤。
您可以使用 Java 安全管理器执行下列安全任务来保护 WebLogic 资源：
有关如何使用 Java 安全管理器执行这些任务的详细信息，请参阅“WebLogic 安全性编程”中的使用 Java 安全管理器保护 WebLogic 资源。
这些安全 API 由 Sun Microsystems, Inc. 开发，提供一个框架用于访问和开发 Java 平台加密功能，开发加密实现、密钥生成和密钥协议以及消息身份验证代码（Message Authentication Code，MAC）算法。
JACC 为 WebLogic Server 域的 EJB 和 Servlet 容器提供备用授权机制。配置 JACC 后，不能将 WebLogic 安全框架访问决策、仲裁和角色映射功能 EJB 和 Servlet 授权决策。JACC 类用于角色到委托人映射，也用于呈现访问决策。不能将 JACC 框架与 WebLogic 安全框架结合起来使用。WebLogic Server 使用的 JACC 类不包括用于呈现决策的策略对象实现，而是依赖于 J2SE 1.4 java.security.Policy 对象。
WebLogic Server 支持基于 Internet Inter-ORB (IIOP)（GIOP 1.2 版）和 CORBA 通用安全互操作性版本 2 (CSIv2) 规范的 Enterprise JavaBean (EJB) 互操作性协议。CSIv2 在 WebLogic Server 中支持：
| 注意： | WebLogic Server 中的 CSIv2 实现通过了 Java 2 Enterprise Edition (J2EE) Compatibility Test Suite（兼容性测试套件，简称 CTS）的一致性测试。 |
CSIv2 实现的外部接口是一个检索 CORBA 对象的用户名和密码的 JAAS LoginModule。此 JAAS LoginModule 可用在 WebLogic Java 客户端中或用在充当另一个 J2EE 应用程序服务器客户端的 WebLogic Server 实例中。CSIv2 支持的 JAAS LoginModule 称为 UsernamePasswordLoginModule，位于 weblogic.security.auth.login 包中。
| 注意： | 有关与 WebLogic Server 群集中 CSIv2 负载平衡支持相关的信息，请参阅“使用 WebLogic Server 群集”中的服务器关系和使用 CSIv2 的 IIOP 客户端身份验证。 |
  
|
