保护面向服务的体系结构（service-oriented architecture，SOA）中的应用程序具有挑战性，因为 SOA 的松耦合特性可能暴露现有安全实现的弱点。以下解决方案包括定义明确的信任模型（基于可接受的验证形式），并糅合了策略、Web 服务安全性和安全工程最佳实践。
引言
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则构造的实现的服务、应用程序以及跨组织操作的松耦合，因此安全对其甚至更为重要。这种环境往往会暴露现有安全实现的弱点或局限性。
即使不考虑通过由模型驱动的开发和基于 SOA 的服务管理所提高的效率，业务应用程序仍须保护信息。只保护周边设施（如防火墙和路由器）是不够的，因为随需应变的企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态信任关系。因此，安全的随需应变企业需要灵活的、可自定义的基础设施，以适应新要求和规章制度。要提供这种灵活性，不应将策略生搬硬套到基础设施中；应该通过由策略驱动的基础设施满足安全模型的要求，这任务可不简单。
本文将阐释业务应用程序利用随需应变安全基础设施的安全功能的方式，以及建立用于保护面向服务的应用程序的编程模型的设计原则。
业务应用程序和安全基础设施
安全集成以及对业务应用程序和信息的访问通常是通过身份验证、授权和责任实现的。企业探讨管理身份验证、授权和责任的方式在很大程度上取决于其对客户、雇员和合作伙伴之间的信任关系的看法；这些关系对业务应用程序安全的影响；以及这些应用程序的相对重要性和安全性。
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护。可能还需要用安全的方式保存敏感信息。必须保证消息源的完整性（如通过公证服务）才能在必要时启用验证、审核和认可。可能需要对敏感信息进行加密以实现机密性，或对其进行数字签名以实现完整性。（数字签名也可用于认可。）完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保护保存的内容以遵守政府规章制度和业界最佳实践的需要。
安全策略的制定和执行以及所执行的安全级别，基本上都取决于企业及其雇员、客户和合作伙伴之间的信任关系。证书和密钥之类的相关技术可用于反映和管理这些信任关系。工具可用于建立业务合作伙伴、客户和企业等之间的信任关系模型并指定信任关系，还可以将信任定义转换成适用于 IT 环境的技术。
SOA 安全模型
SOA 安全模型基于 Web 服务可能需要其中的传入消息以验证一系列声明的过程。名称、密钥、权限和功能都是声明的例子。根据所提供的证据，会在请求者、服务端点和一系列可能的中介之间应用适当的信任模型。
消息可能会通过请求者和目标服务之间的若干中介。端到端安全性必须考虑到请求者、中介和最终端点服务（提供者）之间的信任模型，如图 1 所示。
图 1. 从请求者通过中介到提供者的信任模型
对于消息处理，网络和传输中介（如防火墙、路由器和代理服务器）一般不受信任。应该防止传输中的所有消息受到不可靠中介的篡改。
OASIS Web 服务安全性（Web Services Security，WSS）规范提供对传输中的简单对象访问协议（Simple Object Access Protocol，SOAP）消息的保护。可用 WSS 防止消息的真实性、完整性和机密性受到不可靠网络和传输中介的攻击。
图 2. 消息中介代理信任关系和联合
并不是所有中介都不可靠。Web 服务网关和企业服务总线中介服务都是消息转换中介的例子，其在 SOA 内的功能包括检查，在某些情况下还包括对消息有效负载的修改 [请参阅此系列中的第 4 部分，“IBM 企业服务总线简介”（developerworks，2005 年）]。在设计 SOA 安全基础设施时，请考虑允许某些受信任的中介。
处理请求者和应用程序服务主机之间的信任关系的消息代理可能是另一个受信任的中介。在这种设计中，安全责任由代理和服务端点来分担。如图 2 所示，消息中介将负责消息级安全、请求者和提供者环境之间的身份联合，以及管理请求者和服务提供者之间的信任关系。服务只有为了满足特定于服务的安全要求（如建立（通过中介映射和联合）访问特定于消息有效负载中应用程序数据的服务、完整性和机密性数据的身份）才会继续起安全作用。通过分解业务应用程序中脆弱或复杂的基础设施代码并将其委派给容器，基于 SOA 的安全方法可以提高灵活性并降低发生不测事件的可能性。
消息安全性
WSS 规范还提供一系列有助于 Web 服务开发人员保护 SOAP 交换的基本消息级完整性、机密性和身份验证机制。可用各种方式组合这些机制，以便用各种加密技术建立各种安全模型。
WSS 还提供可扩展的机制，以便将安全令牌与含有各种身份验证及授权格式和机制的消息相关联。例如，客户机可能会提供身份证据及其具有特定业务证书的已签名声明。然后收到这种消息的 Web 服务就可以确定是否要信任其声明和信任的程度。
安全令牌声明可由授权机构核准或不核准。一组已核准的声明通常表示为安全令牌（经过数字签名或受到授权机构加密保护）。X.509 证书就是一个熟悉的已签名安全令牌例子；它断言某人的身份和公钥之间的绑定关系。安全令牌可以“推送到”消息中或者在消息中携带安全令牌，也可以通过引用表示安全令牌，以便接收方从授权机构“拉取”该声明。
因为安全令牌是在信任域内起作用的，所以需要有链接信任域作用范围的方式。可通过协议或通过实现一系列规则强制执行信任策略来手动链接。这样，如果发送方和接收方之间有已确立的信任关系，则可信任未经核准的声明。例如，如果发送方和接收方使用的是其通过带外信任关系建立的可靠连接，则发送方为 Bob 的未核准声明足以让某些接收方认为发送方实际上就是 Bob。在本例中，此可靠连接的存在可作为确凿的证据。
防止消息内容受到非法访问（机密性）或非法修改（完整性）是主要的安全事务。WSS 规范提供通过对主体、标题、附件或其任意组合（或部分）进行加密和/或数字签名保护消息的方法。
身份验证请求基于可选网络、由传输支持的安全性和消息中已批准的信息（声明）的组合，这种技术称为消息源身份验证可能更好一些。通过网络和由传输提供的安全性、消息中已批准的声明，以及用收件人已知的密钥对请求进行加密，请求者可以对收件人进行身份验证。
信任模型
演示安全令牌已授权应用的一种方式是，添加采用相关联密钥（来自于占有证据令牌）的数字签名。这会使请求者可通过将安全令牌（如 X.509 公钥基础设施（Public Key Infrastructure for X.509，PKIX）证书或 X.509 证书）与消息相关联来证明所请求的声明组。
如果请求者没有向服务证明请求的声明所必要的令牌，则可与相应的授权机构（我们称为安全令牌服务）联系，并用正当的声明请求所需的令牌。安全令牌通过发布一系列安全令牌（可用于在不同的信任域之间代理信任关系）来形成信任的基础。
一种机制是应用 WS-Trust（对于有关 WS-Trust 规范的更多信息，请参阅参考资料）中所定义的质询回应协议。这种机制由 Web 服务用来对请求者进行更多质询，以确保消息不过时，以及验证安全令牌的使用是否已经授权。图 3 所示的就是此模型，可以看出任何请求者也都可以是服务，请求者和目标服务都具有受信任的第三方安全令牌服务，这种服务有助于验证每个目标服务策略所需的安全令牌。
图 3. 安全令牌服务
此 SOA 安全模型（声明、策略和安全令牌）还含有并支持若干特定模型，如基于身份的授权、访问控制列表和基于功能的授权。通过该模型可使用现有的技术，如 X.509 公钥证书、基于 XML 的令牌、Kerberos 共享秘密票证，甚至口令摘要。SOA 模型结合 Web 服务安全对话语言（Web Services Secure Conversation Language，WSSC）和 Web 服务策略框架基本要素，这足以构造高级密钥交换、身份验证、基于策略的访问控制、审核和复杂的信任关系。
将对 Web 服务应用策略，Web 服务会从请求者收到可能包括安全令牌的消息，还可能会对其通过 WSSC 机制应用某些保护措施。下面是由 Web 服务的信任引擎执行的主要步骤：
- 验证令牌中的声明是否足以遵从策略，以及消息是否与策略一致。
- 验证申请人的特征是否可由签名来证明。在代理式信任模型中，签名不可以证明申请人的身份；签名可以证明中介（只是可断言申请人的身份）的身份。声明经过批准或不是基于策略。
- 验证安全令牌（包括所有相关和即将颁发的安全令牌）的颁发者是否可信，可以颁发其所作的声明。信任引擎可能需要外部验证或代理令牌（也就是向安全令牌提供服务发送令牌，以便用其交换其他可直接用在其评估中的安全令牌）。
如果满足了这些条件，而且请求者有权执行操作，则服务可以处理服务请求。
可将 IP 安全（IP Security，IPSec）或传输层安全/安全套接字层（Transport Layer Security/Secure Sockets Layer，TLS/SSL）之类的网络和传输保护机制与此 SOA 安全模型结合使用，以支持不同的安全要求和方案。如果可用，作为附加安全技术，请求者应该考虑采用网络或传输安全机制，以便在颁发、验证或更新安全令牌时对收件人预先进行身份验证。
编程模型设计原则
从安全的角度来看，编程模型包括对于谁负责实现安全策略（如基础设施或应用程序）所作的决策，以及需要让请求者得到此信息的哪一部分。除了操作方面，某些设计期间的策略（如在 J2EE 描述符中捕获的）也有助于管理应用程序。是通过使基础设施能够实现安全模型，还是通过将安全的实现转换成每个应用程序中的代码来最大程度地满足业务需求，这是关键实现决策之一。要考虑的另一方面是调用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性？最后，在实现安全解决方案时，应该考虑安全工程——用于构建安全应用程序的工程方法。
由基础设施管理的安全与由应用程序管理的安全
每个组织通常都会让某些人负责确定和实现其安全策略。在许多情况下此过程都是手动的，从而导致组织投入大量资源在不同的实体和应用程序之间协调访问。
我们建议复杂的组织在基础设施中集中实现与解决方案相关的安全策略——也就是验证用户质询（如用户 ID/密码）、控制对应用程序的访问（如对 travelService 执行 reserve() 方法），以及委派身份（如运行方式 travelAgency id），以确保方法一致。可在某些部署构件（如 J2EE 应用程序的部署描述符）中定义初始应用程序安全策略。部署完毕后，熟悉大部分应用程序逻辑时就可以向部署环境提供策略信息了。可将策略声明概括成高级策略要求，以备将来细化成实现约束条件，这被认为是部署阶段的工作。
应用程序设计中引入了有关由基础设施管理的安全与由应用程序管理的安全的决策。安全约束和条件是附加到实现构件的。决定是让基础设施处理安全，还是将安全转换成应用程序中的代码的时机在实现阶段，此时通常可以得到有关应用程序平台（如 Java™ Platform Enterprise Edition (J2EE) 和 Microsoft® .NET）的信息。
我们建议将应用程序的重点放在业务逻辑、延迟服务访问的保护和送往基础设施的消息（承载应用程序的运行时容器）上。在这种由基础设施管理的方法中，附加到设计构件的安全策略将被转换成特定于平台的策略 [例如，通过统一建模语言（Unified Modeling Language，UML）模型表示的要求将转换成 J2EE 部署描述符]。
在由应用程序管理的方法中，安全实现是在应用程序中实现的，必须实现相应的安全调用。即使是由应用程序管理的安全也必须通过 Java 身份验证和授权服务（Java Authentication and Authorization Service，JAAS）将其安全调用（如 authenticate()）转换成相应的特定于平台的功能[如 loginContext.login()]。
授权和访问控制的粒度粗细不等。细粒度访问（对于解决方案本身）与粗粒度访问（对于其操作之一）的选择通常取决于业务和技术考虑。粒度也会受各种因素的影响，包括信息实体的实例（如特定游客的信用帐户概要信息）、上下文信息，如用户特征（如旅行社）、时间约束（如从早上九点到下午五点）、访问目的（如进行旅游预订的目的）、访问路径（例如，内部网请求与外部请求），以及许多其他因素。
可通过定义应用程序角色概括与授权相关的策略，其中的角色是指一组通过其可对特定应用程序资源执行某些操作的权限。例如，旅行应用程序可声明对 ReservationBean 执行的 view() 或 change() 预订方法可由 TravelAgent 角色访问。换句话说，TravelAgent 是由实现方案定义的角色，可以确定可由“旅行社”执行的操作；根据一组用于对各自企业 JavaBean（Enterprise JavaBean，EJB）调用特定方法的权限。在实现阶段不大可能定义的是谁拥有 TravelAgent 特权。用户到角色的指派通常是在部署时开始的，然后会在应用程序的整个生命周期内对其进行管理。清单 1 所示的是用于定义某些基于角色的方法权限的示例代码。
清单 1. 用于定义某些基于角色的方法权限的代码
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-name> view</method-name>
<method-name> change</method-name>
</method>
</method-permission>
|
在执行某些业务逻辑之前要求提供通过身份验证的身份信息的应用程序必须从基础设施中得到该信息。例如，在 J2EE 环境中，运行时会在身份验证后确定用户的身份；应用程序可通过 API（如 getCallerPrincipal()）检索此信息。
选择的灵活性
客户机运行时有时需要某些对访问服务本身的要求或约束（包括身份验证、完整性和机密性要求）。而支持各种客户机运行时（如浏览器客户机、非浏览器客户机和 PDA 瘦客户机）可能是令人满意的。要支持各种客户机运行时，请发布断言客户机运行时必须确保消息机密性，并必须提供用户身份的证据（用户 ID/密码或证书）的策略。身份验证的策略概括可列出替代选项，如可接受的凭据类型，或所信任的凭据颁发机构。
例如，TravelService Web 服务可声明其要求某些安全令牌类型的意图和机密性要求。实现方案可通过描述符支持意图声明。工具则可进而生成必要的机器级详细信息（如 WS-SecurityPolicy 表达式），如清单 2 所示。
清单 2. WS-Security 策略描述符示例
<wsp:Policy>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosV5APREQToken
sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:ProtectionToken>
<sp:SignBeforeEncrypting />
<sp:EncryptSignature />
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedParts>
<sp:Body/>
<sp:Header
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>
|
安全工程
在开发安全解决方案的过程中，安全工程是最佳实践之一——请遵循定义明确的模式，以使您的应用程序、服务或组件可以完全实现其设计者和用户的期望。您应该估计每个实现方案构件中固有的风险，对其进行设计和实现以防其暴露在弱点下（例如，高效的内存管理并避免出现隐蔽的通道）。工具支持和代码评审也有助于将对从中部署解决方案的环境的损害降到最低（或彻底避免）。
总结
SOA 编程模型必须确保每个服务调用都符合对请求者和服务端点均有效的安全策略。安全基础设施（包括对请求者进行身份验证和对其授予服务访问权的能力、基于基本信任模型跨 Web 服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容）形成了有助于保护组件和服务的 SOA 环境的结构。所有 SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。基于 Web 服务安全规范的 Web 服务安全模型和方法有助于解决保护面向服务的应用程序的难题。