内容


IBM WebSphere 开发者技术期刊

通过 WebSphere Application Server V6 实现 Web 服务安全——第 1 部分

安全体系结构介绍

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

摘自 IBM WebSphere 开发者技术期刊

安全体系结构概述

图 1 和图 2 是安全体系结构的示例。这些关系图的目的在于揭示该协议栈中的不同之处,在该协议栈中,客户端和服务之间可能存在中介。它们并不代表实际的基础体系结构。在任何实际基础体系结构中,在关系图的所有层上都存在中介不太可能。但是,一种或多种类型的中介可能存在于特定的体系结构中。

在这些图中,每个中介下方为该类型中介的实现示例列表。不同的技术被划分为不同的中介,因为它们通常以这种方式实现,但它们也可能共存于同一节点中。因此,举例来说,IPSec 连接既可以通过专用的 IPSec 路由器进行初始化,也可以在某个 HTTP 服务器或某个应用程序节点上的软件中进行初始化。

下图中的协议栈之间的黑线流向代表安全上下文的流而不是信息流。信息总是从应用程序流向应用程序。

图 1. 安全体系结构(客户端的角度)
图 1. 安全体系结构(客户端的角度)
图 1. 安全体系结构(客户端的角度)

示例服务器端实现中列出的 HTTP 服务器具有已安装插件的 WebSphere Application Server(以下称为 Application Server),并将 HTTP 请求转发到 Application Server process 进行处理。如果它是真正独立的 HTTP 服务器,则称为 HTTP 端点应更恰当,但在我们的讨论中,由于使用了 Application Server 插件,因此 Application Server 是真正的 HTTP 端点。

图 2. 安全体系结构(服务器的角度)
图 2. 安全体系结构(服务器的角度)
图 2. 安全体系结构(服务器的角度)

SOAP(甚至对于 HTTP)可以具有多个与消息关联的端点。它们按角色进行标识。SOAP Header 可以针对特定的 SOAP 端点或角色。如果 SOAP 处理器以 Header 指示的角色进行处理,那么它就是该 Header 的 SOAP 端点。如果 SOAP 处理器以其他角色进行处理,那么它就不是该 Header 的 SOAP 端点,Header 必须向下流动以便进行进一步处理。

Web 服务网关是 SOAP 处理器的一个例子,它有时为最终接收方角色(在这里意味着服务提供者),有时为其他角色。当网关将传入消息转换为不支持 SOAP 安全性的协议(例如 RMI/IIOP)时,网关必须自己处理消息中的 Web 服务安全 Header。这意味着要么客户端必须将消息定位到网关具有的角色,要么网关必须作为最终接受方以便进行安全处理。在本例中,网关是有效的服务提供者,并简单地利用下游的服务作为它所提供服务的一部分。

体系结构

在本文的余下部分,您将了解可以通过 Application Server Version 6 实现的下列 Web 服务安全体系结构以及每种体系结构的优缺点:

传输安全体系结构:

Web 服务安全 (WS-Security) 体系结构:

发布/订阅体系结构

Tivoli® 体系结构:

DataPower® XS40 体系结构

IPSec

图 3 显示了使用 IPSec 的体系结构。

图 3. IPSec
图 3. IPSec
图 3. IPSec

上面的基础体系结构示例使用协议栈表示法。它通过包括从客户端和服务端视图中选择的中介进行构造,如图 1 和图 2 所示。

在此体系结构中,客户端基础结构中的 IPSec 路由器对发往服务基础结构的通信进行加密。服务基础结构中的 IPSec 路由器对 IP 数据包进行解密,并将其转发到服务所在的计算机中进行处理。所有从客户端基础结构或网络到服务基础结构或网络,或者从服务端到客户端的通信都将被加密。这种加密应用到所有的 IP 数据包,而不会根据应用程序或服务调用情况进行启用或禁用。这种配置通常称为虚拟专用网(Virtual Private Network,VPN)。注意,IPSec 连接可以通过客户端计算机上的软件而不是专用 IPSec 路由器建立,但使用专用设备具有更高的可伸缩性。

在 IPSec 为我们的服务提供机密性和完整性的同时,简单 HTTP 基本身份验证 Header 可以提供标识和身份验证。所有重要的客户端技术都支持此技术。

注意,WebSphere 并不提供 IPSec 技术。

通过将 HTTP 服务器作为 SSL 端点实现传输安全

图 4 显示了通过将 HTTP 服务器作为 SSL 端点实现传输安全的体系结构。

图 4. 通过将 HTTP 服务器作为 SSL 端点实现传输安全
图 4. 通过将 HTTP 服务器作为 SSL 端点实现传输安全
图 4. 通过将 HTTP 服务器作为 SSL 端点实现传输安全

此体系结构是当今大多数生产 Web 服务的安全实现方式。在此体系结构中,客户端应用程序(独立的 Java™ 应用程序、.Net 应用程序、servlet 等)同承载服务的服务器建立 SSL 会话,然后通过 SSL 通道调用服务。在安全的 SSL 通道建立(在此过程中对服务器计算机进行身份验证)之前,不会传输任何应用程序数据。注意,该技术可用于所有能建立 SSL 连接的客户端类型(换言之,几乎所有客户端技术)。与此相反,Application Server 的 WS-Security 目前尚不能用于如独立的 (Java 2 Standard Edition) Java 应用程序等。作为一种成熟的技术,SSL 已经过多年的优化。它可支持硬件加速,并可在不同供应商之间实现互操作。基于这些原因,该体系结构对于高吞吐量情况是非常好的选择,它可承受以下故障:

  • 应用于通信的安全性在 SSL 端点结束,而不是覆盖实际的服务。可以通过来自 SSL 端点的第二个 SSL 连接来保证通信对服务提供者是安全的,但消息在中介 SSL 端点应用程序(例如 HTTP 服务器)中则为明文。
  • 客户端和服务端 SSL 端点之间不能加入其他中介。这会影响客户端或服务端的基于内容的路由或记录选项。通常,最初的拓扑结构并不要求另外的中介,因此这成为了一个好的选择。由于需求随时间而发生变化,后来您可能需要插入某种代理或拒绝服务 (DoS) 预防设备或其他中介。您可以在初始 SSL 端点后插入该设备,否则它会成为初始 SSL 端点本身。
  • 由于所有应用程序数据通过对称密钥技术进行加密后才进行交换,因此没有提供不可否认特性。

注意,SSL 端点可以是 Web 服务网关,而不是承载服务的 Application Server 实例前的 HTTP 服务器。在本例中,网关可执行某些基于内容的路由或记录功能。接下来我们将讨论这种变化。

我们再次选择使用 HTTP 基本身份验证 Header 将调用方的标识传播给提供者。我们还可选择客户端 SSL 证书,这在客户端和服务处于单一实体管理控制中或缺少足够的客户端来合理地管理客户端证书的情况下是可行的解决方案。当然,基于用户名和密码的帐户也必须进行管理。在接下来的体系结构中我们将讨论如果管理这些帐户的问题。使用 HTTP 基本身份验证,还允许凭据从 HTTP 客户端传播到 HTTP 端点 (Application Server)。如果我们使用了客户端 SSL 证书,标识将只被传播到第一个 SSL 端点。因此,我们需要使用另外的技术来向下传播。这是因此客户端的标识在 SSL 握手期间才为服务器所知,而客户端只同链上的第一个 SSL 端点执行该过程。

通过将 Web 服务网关作为 SSL 端点实现传输安全

图 5 显示了通过将 Web 服务网关作为 SSL 端点实现传输安全的体系结构。

图 5. 通过将 Web 服务网关作为 SSL 端点实现传输安全
图 5. 通过将 Web 服务网关作为 SSL 端点实现传输安全
图 5. 通过将 Web 服务网关作为 SSL 端点实现传输安全

此体系结构与前面将 HTTP 服务器作为 SSL 端点的体系结构类似。此体系结构具有下列优点:

  • 现在,有一个定义良好的位置(网关中介)来添加中介功能,如服务器端的记录或基于内容的路由等。
  • 网关可以执行传输转换,并且可以将消息从入站服务发送到使用不同传输协议(如 SOAP/JMS)的服务。
  • 网关可以使用不同于 HTTP 基本身份验证的机制(例如 IBM 专用的 LTPA 令牌)来将安全上下文(入站调用方的标识)传播到服务,这可以减少服务端身份验证开销。如果网关和服务提供者之间的传输支持 SOAP 和 Web 服务安全,网关甚至可以使用 WS-Security 将上下文传回到服务实现。

另一方面,从功能的角度来看,SSL 连接进一步到服务才终止,而不像以前将 HTTP 服务器作为 SSL 端点的情况。有些客户可能感觉 SSL 连接应当尽量在靠近服务的位置结束,他们甚至打算由 Application Server 来终止 SSL 连接本身而去掉所有中介。这显然是可能的,并且相当有效,尽管灵活性有些不足。

调用方的标识的传播方式同前面的体系结构相同,且适用于相同的注意事项。

WS-Security

图 6 显示了 WS-security 体系结构。

图 6. WS-Security
图 6. WS-Security
图 6. WS-Security

此体系结构使用 WS-Security 来提供端到端安全和可能的不可否认性(如果服务在删除安全前保存入站消息)。SSL 用于在不可信网络中提供附加安全级别。通过使用 SSL,我们可以确保在交换任何应用程序数据前,能识别服务器端并建立安全通道。在使用 WS-security 时,应用程序是在确认目的地标识前进行传输的,这可能面临离线攻击风险。但是,由于 WS-Security 常用的密钥长度可以提供相当高的保护级别(256 位对称或 1024 位非对称),因此将离线攻击的威胁降到最低限度。

上面例子是入门级的 WS-Security 体系结构。客户端和服务提供者之间的关系为 1 对 1。客户端配置为信任服务密钥或令牌,而服务配置为信任客户端密钥或令牌。这对于入门级 WS-Security 完全足够,但当涉及大量客户端和服务时则无法具有足够的可伸缩性。

其中存在两个问题:

  • 第一个问题是客户端和服务器端相互信任令牌和密钥的需要。
  • 第二个问题是客户端主体需要存在于服务用户注册表中(可能反之亦然)。

我们使用某些形式的第三方,例如信任服务或 Web 服务网关,来解决密钥/令牌问题,同时使用标识联合来解决标识问题。在以下部分中我们将讨论使用这些技术的体系结构。

服务器端网关具有指定给 WS-Security Header 的角色

图 7 显示了服务器端网关具有指定给 WS-Security Header 的角色的体系结构。

图 7. 服务器端网关具有指定给 WS-Security Header 的角色
图 7. 服务器端网关具有指定给 WS-Security Header 的角色
图 7. 服务器端网关具有指定给 WS-Security Header 的角色

此体系结构部分类似于网关作为 SSL 端点的体系结构。与该体系结构类似,使用此体系结构,可以在一点(网关)管理所有用于为通过网关公开的服务提供完整性和机密性的密钥和令牌。这意味着调用通过此网关公开的任意数量的服务的客户端只需配置为信任来自此单一网关的密钥和令牌,而不必配置为信任来自每个服务的密钥和令牌。此网关需要配置为信任来自每个客户端的密钥和令牌。因此,使用上述 Web 服务安全的简单体系结构可以部分地解决令牌信任可伸缩性问题,但无法解决帐户维护可伸缩性问题。

此体系结构不同于网关作为 SSL 端点的体系结构,并可提供以下灵活性:

  • 可以使用不同的令牌类型来将客户端或用户 ID 传播到网关,这些令牌类型的例子包括目前的 UsernameToken、X.509 和 LTPA 令牌以及将来的 Kerberos 令牌。
  • 必要时可以将其他 SSL 端点添加到客户端和网关之间。例如,服务器端基础结构中的某种反向 Web 代理可能提供某些缓存功能。
  • 在此体系结构中,不可否认性至少是可能的(尽管需要在网关中自定义代码)。

在不利的方面,除了稍后将要讨论的 DataPower 设备外,WS-Security仍然比 SSL 慢一个数量级且需要消耗大量资源,因此并不适合所有应用场景。

服务器端的网关不具有指定给 WS-Security Header 的角色

图 8 显示了服务器端网关不具有指定给 WS-Security Header 的角色的体系结构。

图 8. 服务器端网关不具有指定给 WS-Security Header 的角色
图 8. 服务器端网关不具有指定给 WS-Security Header 的角色
图 8. 服务器端网关不具有指定给 WS-Security Header 的角色

此体系结构提供网关作为 SSL 端点的体系结构简单 WS-Security 体系结构的综合特性。它可提供以下功能:

  • 定义良好的位置(网关中介),用于添加中介功能,如服务器端的记录或基于内容的路由(假定将用于基于内容的路由决策的内容未进行加密)等。
  • 网关可以执行传输转换,并且可以将消息发送到使用不同基于 SOAP 的传输协议的服务。
  • 网关提供的中介之一可以用于记录处于安全状态的入站消息,从而实现不可否认性。

此结构与网关作为 SSL 端点的体系结构不同,但类似于简单 WS-Security 体系结构,它需要在每个参与通信的客户端和服务对之间建立令牌信任关系。因此,它可提供与使用 Web 服务安全的简单体系结构相同的可伸缩性。

网关、中间层和服务端后端

图 9 显示了使用网关、中间层和服务器端后端的体系结构:

图 9. 网关、中间层和服务器端后端
图 9. 网关、中间层和服务器端后端
图 9. 网关、中间层和服务器端后端

此体系结构与服务器端网关不具有安全角色的体系结构相同,同时增加了对下游服务的调用,并将其作为客户端调用的服务实现的组成部分。这是一种典型情况。在前面的体系结构中所讨论的所有注意事项和可能性也适用于中间层服务和下游服务之间,尽管在图 9 中并未显示这一特性。目前的最佳实践是将传入标识主体传播到下游服务。这允许下游服务管理其自身的审核和帐户信息。如果只有中间层服务的标识传播到下游服务,则下游服务不能对服务访问审核和授权进行正确的控制。

客户端和服务端的网关

图 10 显示了使用客户端和服务端的网关的体系结构。

图 10. 客户端和服务端的网关
图 10. 客户端和服务端的网关
图 10. 客户端和服务端的网关

此体系结构为客户端和服务实现提供了选择不同于网关之间使用的外部协议的内部协议的灵活性。此体系结构的优点还包括只需要网关之间的信任关系,而无需每个客户端和服务之间的独立关系。但是,这需要将关系绑定更改到网关之间,而不是单独的客户端和服务之间。如果使用适当的传输协议,单个客户端/用户主体可以在客户端和服务之间进行传播。例如,客户端可以使用相互 SSL 对网关进行身份验证。客户端网关使用服务网关的身份断言来传播客户端主体。服务网关将客户端主体传播到服务提供者。这只在客户端主体存在于服务平台用户注册表中时才能使用。因此,我们通过这些方式缓解了令牌信任可伸缩性问题。但是,我们尚未解决帐户维护可伸缩性问题。如果我们要取消对客户端主体必须存在于服务平台用户注册表中的要求,则可以在客户端网关中进行身份映射,以便传播代表客户端并存在于服务用户注册表中的标识。下面的一个部分将说明如何利用 Tivoli Federated Identity Manger 来执行此映射。

在此体系结构中,客户端还可得益于网关提供的特性,例如定义良好的位置,以便插入中介、进行协议转换和安全协议转换等。

发布/订阅

图 11 所示为发布/订阅体系结构:

图 11. 发布/订阅
图 11. 发布/订阅
图 11. 发布/订阅

在发布/订阅体系结构中不容易处理好机密性,因为我们不能简单地使用公钥基础结构 (PKI) 技术,尽管我们可以在客户端和服务提供者之间进行的一对一交互中使用此技术。对于一对一交互,我们通常使用服务公钥来加密信息并提供机密性。因为我们现在具有多个服务提供者,这就出现了问题:您将使用谁的公钥来进行加密?

一种解决方案是使用预先约定的安全密钥(对称密钥加密体系,例如 DES 或 AES)进行加密。另一种解决方案是在服务提供者之间共享 PKI 私钥。第二种方法比较恰当,因为 PKI 中的私钥通常用于标识单个主体,而不是任何具有角色的主体,当多个主体共享密钥时,可以更准确地描述具体情况。

如果能使所有的客户端和服务提供者加入相同的 Kerberos 域,然后当 Application Server 支持时,Kerberos 协议就可提供该场景下的加密密钥。由于发送方的私钥用于签名(确保完整性和不可否认性),因此我们需要更改我们对安全组件使用 PKI 的方式。

此外,其他消息交换模式也受到该问题的影响。基本上,只要单个消息被绑定到多个端点,就会出现此问题。一种解决方案是重新定义业务问题,以使第一个端点成为来自客户端的唯一真实端点(从客户端的角度),任何其他端点都是服务的实现细节。然后,该服务可以自由地将它选择的任何一种安全性用于所调用的下游服务。这一解释使得可以将 SSL 用于从客户端到发布/订阅中心,而从发布/订阅中心到订户则使用独立的 SSL 连接。

Tivoli Access Manager

图 12 显示了使用 Tivoli Access Manager 的简单体系结构:

图 12. Tivoli Access Manager
图 12. Tivoli Access Manager
图 12. Tivoli Access Manager

简而言之,Tivoli Access Manager 包括大量的组件,其中之一就是名为 WebSEAL 安全代理服务器,它能:

  • 作为服务器或流行 Web 服务器插件运行
  • 添加 SPNEGO (Kerberos) 功能,以允许用户对基于 Web 的应用程序进行身份验证,而不会在其登录到其操作系统时遇到困难。
  • 使用专有的 CSSO 技术提供跨站点单点登录 (CSSO)。
  • 为 Application Server 进行授权决策。J2EE 授权决策则委托给 Access Manager 授权服务。这允许要定义的角色跨越企业资源,而不只是具有单个 Application Server 角色、Windows 角色、RACF 角色等。
  • 通过 HTTP 或 HTTPS 用于 Web 服务。

在此体系结构中,我们利用 WebSEAL 的功能来对传入 Web 连接执行 SPNEGO 身份验证。对于 .Net 客户端调用 Web 服务,这是一种流行的配置。在本例中,SPNEGO 使用的安全令牌是 Active Directory 提供的 Kerberos 令牌。也可以使用其他客户端,如 Linux 上的 Mozilla。基于 Java 的 Kerberos 密钥分发中心 (KDC) 未来可能会得到更加广泛的使用,它将推动 Kerberos 的普及,并使更多客户端能够使用 Kerberos 令牌。

使用 Kerberos 令牌的唯一方式是在 HTTP Header 中进行传递。另一种方式可能会逐渐流行,即在 WS-Security Header 中进行传递。要在 WS-Security Header 中使用 Kerberos 令牌,我们需要首先了解 Tivoli Federated Identity Manager。注意,在 Tivoli Access Manager 体系结构中,客户端和服务提供者必须是同一 Kerberos 域或具有信任关系的多个 Kerberos 域的成员。

Tivoli Federated Identity Manager

图 13 显示了使用 Tivoli Federated Identity Manager 的简单体系结构:

图 13. Tivoli Federated Identity Manager
图 13. Tivoli Federated Identity Manager
图 13. Tivoli Federated Identity Manager

简而言之,Tivoli Federated Identity Manager 能:

  • 实现为 Application Server 应用程序
  • 依赖于 Tivoli Access Manager
  • 提供安全令牌服务功能(WS-Trust 和 WS-Federation)
  • 添加安全断言标记语言(Assertion Markup Language,SAML)令牌支持,并可以根据 SAML HTTP 概要或 WS-Security Header 中的令牌对其进行使用。
  • 提供 Liberty Aliance Project 标识联合协议实现。

在此体系结构中,Tivoli Federated Identity Manger 安装到 Web 服务网关节点,用于验证接收到的令牌,并进行从客户端用户域到服务用户域的传入标识映射。这种映射是可配置的,例如将一组传入用户映射到单个服务端用户。此外,Application Server 提供的其他 Identify Manager 功能包括使用 SAML 和 Kerberos 令牌,以及将传入的令牌类型映射到不同的令牌类型,从而传播到服务提供者。

Identity Manager 的实例可以安装在客户端,以提供令牌创建、映射和出站标识映射等功能。

在此体系结构中,我们通过在 Identify Manager 信任服务中进行集中信任管理来解决令牌信任可伸缩性问题。此外,我们还通过利用 Identity Manager 的凭据映射功能缓解了帐户维护的可伸缩性问题。这里还可以使用分布式单点登录协议,以使帐户管理中的高开销部分集中到一个点上。

DataPower

图 14 显示了使用 DataPower 的简单体系结构。

图 14. DataPower
图 14. DataPower
图 14. DataPower

简而言之,DataPower XS40 Security 设备可提供下列功能:

  • 全面的安全性——在单个设备中提供所有 XML 和 TLS 安全功能
  • 性能——确保安全目标而不会牺牲性能
  • 基于 XML 的灵活性——面向未来,适应标准、策略和合作伙伴的变化
  • 硬件装置——混合设备同时确保多个应用程序的安全
  • 易于集成——可与现有安全系统的实现进行互操作,并进行增强
  • XML 转换——包括 XPath/XSLT 加速特性

这与服务器端网关具有指定给 WS-Security Header 的角色体系结构相同,但其中使用 XS40 代替 Web 服务网关。此体系结构使得我们可以扩展解决方案,因为 XS40 可以通过很小的开销来处理 Web 服务安全。由于它基于网关体系结构,因此尽管能部分地解决令牌信任可伸缩性问题,但无法解决帐户维护可伸缩性问题。

总结

本文介绍了一些简单的 Web 服务安全体系结构。本系列的后续文章将提供有关如何使用 IBM 产品实现这些体系结构的循序渐进说明,并对如何选择令牌提供进一步的建议。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services
ArticleID=141724
ArticleTitle=IBM WebSphere 开发者技术期刊: 通过 WebSphere Application Server V6 实现 Web 服务安全——第 1 部分
publish-date=05082006