让SOA不断成熟

申请免费试用、咨询电话：400-8352-114

如何让SOA不断成熟，以满足安全和治理的需要？如今XML安全方面的标准和规范有哪些？它们彼此是如何协同工作的？如何以可扩展的方式来实施这些标准，又不牺牲性能和可维护性？本文试图解答这些问题。

如今，全球各地的许多企业都在迅速采用面向服务的架构（SOA）。数据和应用程序曾经相互独立，而现在却要跨多个部门和组织作为服务来提供。虽然安全在过去属于IT领域，但SOA治理扩大了安全的范畴，包含组织策略和实践，因而涵盖了业务领域。如何让SOA不断成熟，以满足安全和治理的需要？如今XML安全方面的标准和规范有哪些？它们彼此是如何协同工作的？如何以可扩展的方式来实施这些标准，又不牺牲性能和可维护性？本文试图解答这些问题。

不妨看一下SOA的几个应用实例。以供应链管理为例：诸多生产商、零售商和消费者相互联系，使用众多的系统和应用程序，主要通过因特网来联系。SOA是实现这种松散耦合的交互关系的理想机制。企业级SOA的一个必要部分就是，把安全服务和治理策略运用于交易合作伙伴之间的各个联系层面上。

如果客户在某零售商的网站上下订单，显而易见，订单处理事务必须是安全可靠的。然而，事实不像表面上那么简单。零售商的订单履行应用应当涉及与库存管理系统的交互关系。一旦所订产品准备送货，零售商就与负责送货的交易合作伙伴联系，并应当为客户提供可以浏览订单状态的服务。这种相互关系都需要应用层实现安全，传输协议层通常也需要实现安全。另外，组织必须制订及管理各种策略：谁拥有数据？谁对该数据的真实性负责？各部门和交易合作伙伴如何共享数据？这就是SOA治理所要解决的任务。

这些相互关系带来了类似客户在网站上下订单的需求。在这两个交易合作伙伴交互信息的过程中，必须实行安全策略，还要确定治理服务的策略。

另一个应用实例就是生产商的产品开发生命周期。这个过程可能涉及外部的交易合作伙伴，也可能不涉及，但一家大型生产商通常有好几个部门参与一个制成品的生产。SOA提供了可重复使用、灵活开发的好处，哪怕是在生产商并不涉及外部合作伙伴的场景下。另外，这里需要同样的安全和策略需求。

这些场景所共有的安全需求包括如下几个方面：

● 验证:我怎么知道你的身份是正确的？

● 授权:你有权执行这笔事务吗？

● 完整性:你发送的数据跟我收到的数据一样吗？

● 签名:创建及验证类似手写签名的电子签名。

● 机密性:我们确信没有人读取你发给我的数据吗？

● 审查:把所有事务记录下来，以便事后验证。

● 不可否认性：发送方和接收方都可以向第三方（如法官）证实事务中发送及收到的是同一数据。

由于应用间各自独立的身份安全数量激增，其他安全需求如单次登录（SSO）已变得很重要。威胁预防也渐渐成了另一项重要的安全需求，以便排除不良数据（如间谍软件和恶意软件等）。

XML安全标准和SOA

XML是基于标准的选择，体现了上述需求，因而XML安全标准可以用来满足需求。XML安全标准充分利用了现有的XML标准，还能改进这些标准，方法如下：

● XML安全标准定义了表示安全信息的XML词汇，使用XML模式（XML Schema）等XML技术来定义，譬如，用XML签名语法和处理标准（XML-Signature Syntax and Processing）定义的 < KeyInfo>元素，建议用于传输、签名或者加密密钥信息。

● XML安全标准尽量使用其他现有的XML标准，以便充分利用现有的XML成果。譬如说，XML签名语法和处理标准允许XPath表达式提取XML的一部分进行处理。值得一提的是，既有的XML安全标准出现之前，是不可能实现这种有选择的签名处理的。要么整个文档被签名，要么根本不签名。XML安全标准旨在提供XML的灵活性和扩展性。它们让安全可以应用于XML文档、XML元素和元素内容以及任意的二进制文档。它们通过使用XML命名空间和可扩展的XML模式定义，支持XML词汇的扩展。

● XML安全技术可以应用于端到端安全，如果XML消息通过众多处理中介来发送，这需要特别重视。持久性安全与内容相关，而不是与传输管道相关。内容仍然具有安全性。XML安全技术还可以结合传输安全技术使用，譬如安全套接层和传输层安全（SSL/TLS）。这里要强调的另一点就是，用于SSO功能的身份也随同消息一起传输。

● XML安全技术尽量重复使用现有的加密和安全技术，不需要重复工作。譬如说，需要时，无须重新定义就可以使用X.509 V3证书——它们只是采用文本格式编码而成。现有的算法如SHA1摘要算法也通过把惟一的URI标识符进行关联、定义在XML安全处理模型中如何使用，从而被引入到XML安全标准世界。值得一提的是，URI标识符普遍应用于XML安全，用于加密和签名算法，而不仅仅用于散列算法。

主要的XML安全标准如下：XML加密、XML签名语法和处理、数字签名、XML密钥管理规范（XKMS）。

XML加密是万维网联盟（W3C）制订的一项规范，它为需要安全交换结构化数据的应用提供了端到端安全性。正如我们所知，XML本身就是对数据进行结构化处理的最流行的技术。因此，基于XML的加密自然是满足复杂需求的方法，可实现数据交换应用中的安全。

W3C推荐的XML签名语法和处理标准提供了完整性、消息验证和签名者验证等服务。XML签名是为了用于XML事务而设计的数字签名。这项标准定义了一种模式，用于记录应用于任意（但往往是XML）数据的数字签名操作的结果。与没有XML识别功能的数字签名（如公钥加密标准即PKCS）一样，XML签名为签名的数据添加了验证、数据完整性以及支持不可否认性的功能。然而，与非XML签名语法和处理标准不同的是，XML签名语法和处理标准旨在认可及利用因特网和XML。

数字证书是类似网上护照的电子文件。它们由可信的第三方即证书认证中心（CA）颁发，该机构负责验证证书持有者的身份。

作为W3C的一项备忘录，XKMS简化了使用公钥基础设施（PKI）和数字证书来保护基于XML的因特网事务安全的工作。它为分发及注册适合于结合W3C的XML签名语法和处理标准使用的公钥规定了协议。XKMS由两部分组成：XML密钥信息服务规范（X-KISS）和XML密钥注册服务规范（X-KRSS）。

从前面举例的供应链使用实例知道，通过因特网访问信息的功能对解决方案来说至关重要。Web服务可以实现这种功能，因为它们允许通过网络交换信息。Web服务基于以下三项重要标准：

● 简单对象访问协议（SOAP）：数据传输协议。

● Web服务描述语言（WSDL）：Web服务描述语言。

● 通用描述、发现和集成（UDDI）：确定Web服务位置的注册中心。

请注意，所有上述标准都可以用XML来定义。不过，本文举例的供应链解决方案必须具体解决两个问题：

一、只允许授权用户可以访问基于XML的Web服务，这可以通过可扩展访问控制标记语言（XACML）和Web服务策略（WS-Policy）两个标准来解决；

二、保护Web服务环境中交换的XML消息的完整性和机密性，这可以通过Web服务安全（WSS）和安全声明标记语言（SAML）来解决。

本文基本介绍了Web服务策略、WSS、SAML、XACML以及XQuery和XML数据库如何赋予安全。WSS在SOAP环境下提供了消息保护。SAML和XACML支持授权，并且大力支持大规模分布式系统。最重要的是，所有这些标准都可以使用XML表示信息。Web服务策略、WSS、SAML和XACML都有一些共同之处。虽然所有这些标准都能够使用前些年使用的安全服务，但各自都有具体的特性，旨在适用于大规模分布式环境，譬如因特网。另外，这些标准可以使用及集成原先就有的安全标准。

正如前文所述，这些标准使用XML。XML使诸多技术可以轻松扩展，以满足特殊需求，而使用旧格式不可能做到这点。另外，XML允许实施者使用现有的许多软件工具进行处理。以WSS为例，它旨在与SOAP的语法和处理模型紧密集成，该模型用XML来定义。

另外，XML是一门标记语言，能够标记不同数据源的信息内容，包括结构化和半结构化文档、关系数据库和对象储存库。由于这么多采用XML格式的重要数据可供使用，这些数据可以查询及挖掘，以获得进一步的适用性，就显得极其重要。

查询语言是XQuery，它能够理解XML，并且针对各种XML数据表示查询，无论是不是实际保存在XML中，还是通过中间件作为XML来浏览。XQuery广泛适用于许多类型的XML数据源。

为XML数据添加持久性的推荐方法就是，使用这样的本地XML数据库技术，不但可以把XML作为另一个关系工件来对待，还可以作为自然的XML工件来对待。XML数据库管理服务器（XDMS）是企业级XML持久性机制，它具有传统关系数据库的所有功能。具有功能强大的XML索引、分析及加速等特性的XDMS是一大有利因素。

Web服务策略

如图1所示，Web服务策略框架提供了通用模型和相应语法，以描述及传达Web服务的策略。Web服务策略定义了一套基本的构件，可由其他Web服务规范使用及扩展，从而描述一系列广泛的服务需求、选项及功能。

Web服务策略为表示基于XML Web服务的系统里面实体具有的功能、需求和一般特性提供了灵活、可扩展的语法。Web服务策略定义了一个框架和模型，用于把这些属性表示成策略。策略表达式允许简单的说明性声明，也允许比较复杂的条件声明。

Web服务策略定义的策略是一个或者多个策略声明的集合体。有些声明规定了最终在传输过程中予以显示的传统需求和功能（譬如验证方案和传输协议选择）。有些声明规定了不在传输过程中予以显示、但对服务的合理选择及使用至关重要的需求和功能（譬如隐私策略和服务质量特性）。Web服务策略提供了单一的策略语法，以便能一致地考虑这两种声明。

用XML表示策略声明称为策略表达式。只要使用策略操作符：All、ExactlyOne和OneOrMore等，就可以合并策略声明。

下面演示了一项策略的简单示例：

< policy Priority="200">

< All>

< Language Usage="Required" Language ="it" />

< ExactlyOne>

< SecurityToken TokenType="UsernameToken" Usage="Required">

< Claims>

< Username>Claudio< /Username>

< UsePassword/>

< /Claims>

< /SecurityToken>

< SecurityToken TokenType="X509" Usage="Required">

< Claims>

< SubjectName>Role=Student< /SubjectName>

< /Claims>

< /SecurityToken>

< /ExactlyOne>

< /All>

< /policy>

与策略相关的其他规范是：Web服务策略声明语言；Web服务安全策略语言；Web服务策略附件；针对Web服务策略、Web服务授权和Web服务可靠消息传送等其他技术的策略。

为了便于管理，还要有策略储存库（policy repository）。这个管理工具可以为插入、修改及删除策略提供接口。它应当可以提供与请求者相关的所有策略，可以通过XML数据库获得策略。用于XML的简单API（SAX）解析器速度快、占用内存小，可以对XML数据进行解析。

WSS

WSS由结构化信息标准促进组织（OASIS）通过Web服务安全技术委员会开发而成，它定义了使用XML安全标准把数字签名和加密运用于SOAP文档的标准方法。WSS规定了如何保护在网络上传送的SOAP消息，包括验证、完整性保护和机密性。它没有规定如何实施访问控制，但提供了可用于这类控制的信息。WSS允许有选择地使用加密。譬如说，它允许应用防火墙检查未经加密的消息。

此外，WSS允许基础设施选择方面有更大的灵活性。它不但可以利用X.509技术，还可以利用Kerberos、SAML或者普通的用户名和口令。因为WSS在SOAP层操作，所以它可以连同消息一起在整个网络上传输，即使该消息被查询或者被保存，也会保留下来。

WSS使用W3C开发的XML签名语法和处理及XML加密两项标准。WSS的操作方式是，把名为security的XML元素插入到SOAP头里面。SOAP头包含了运用于该消息的验证、数字签名和加密方面的所有信息。它为接收方提供了对消息进行解密及验证所必不可少的信息。可以使用X.509证书、Kerberos票据、SAML声明或者其他方法来规定密钥和授权信息。

带有< security>元素的SOAP信封示例如下：

< S:Envelope>

< S:Header>

< wsse:Security S:mustUnderstand="1"

xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">

< wsse:BinarySecurityToken EncodingType="wsse:Base64Binary">

MIIDQTCC4ZzO7tIgerPlaid1q ... [truncated]

< /wsse:BinarySecurityToken>

< ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

....XML Signature...

< /ds:Signature>

< /wsse:Security>

< /S:Header>

< S:Body>

< m:OrderAircraft quantity="1" type="777" config="Atlantic"

xmlns:m="http://www.rdta.com/XMLDatabaseOrderSubmission"/>

< /S:Body>

< S:Envelope>

Web服务安全会话语言是另一项有用的规范——它允许使用对称密钥在Web服务请求方和Web服务之间创建会话。Web服务安全会话规范好比SSL，也涉及对称密钥协商过程，以简化加密消息的传输。微软的Web Services Enhancement 2.0工具包里面就含有Web服务安全会话规范，但目前还没有Java实现方案。

SAML

XML安全声明标记语言（SAML）定义了共享安全声明（包括验证和授权声明）的XML词汇，能够实现单次登记以及第三方管理这些功能。它还定义了请求/响应协议定义和XML协议（SOAP）绑定。SAML规范定义了一般的声明框架，允许为声明赋予有效期限，并允许声明可以针对特定受众（避免有可能被人滥用）。声明与特定的“主题”或者命名实体联系起来。

SAML是一种标准方法，可以通过跨越领域界限的异构分布式系统，交换安全及相关的数据。授权和审查跟踪是大家熟悉的两项安全服务。在过去，大多数系统是基于这种假定而设计的：一个系统会拥有进行访问控制决策所需要的所有信息；所有消息会记录在审查跟踪里面。然而，大规模分布式系统总是由多家组织、使用多种产品共同组建而成的。因而，用户可能会由不同的认证中心使用不同的方法来加以验证。此外，不同的认证中心保留了有关用户特性和属性的不同信息。集中所有功能和信息根本就不切合实际。SAML提供了表示验证和用户属性的标准格式，并提供了请求及发送验证和用户属性的协议。

SAML规范负责定义：

● 表示验证和授权声明的词汇，允许表明验证和授权如何进行、何时进行的语句可以在多方之间传输。

● 请求响应协议，以传输SAML声明以及XML协议（SOAP）绑定。

● 惟一标识符（URN），用于不同的验证机制和授权操作。

● 数字签名如何与声明进行联系。

● SAML Token Profile，它描述了SAML声明如何由< wsse:security>标头携带及引用、SAML声明如何结合XML签名语法和处理标准使用，从而把声明的语句（譬如claims语句）绑定到SOAP消息上。

XACML

虽然SAML为进行验证和授权声明、使用XML传输这些声明提供了机制，但还需要词汇来表示进行授权决策所需的规则。XML访问控制标记语言（XACML）就是专门为表示授权规则而开发的。

XACML是表示访问控制策略的语言。换句话说，它可以保护数据交换过程中的内容。访问控制列表（ACL）缺乏表示实际系统中往往需要的复杂策略这一功能。因而，访问控制策略往往嵌入在应用代码当中。这给改变策略、甚至发现哪些策略在执行增添了难度。

XACML能够使用几乎各种现有的信息，从而确定是否允许对某资源的访问。它也可以把额外操作（名为义务）与决策联系起来——譬如说，要求一旦过了某段时间，就销毁请求的数据。

XACML根据资源属性（包括资源内容）或者环境因素（譬如日期、时间或者位置）来进行决策。它还会把与请求有关的各方具有的属性考虑进来，譬如角色或者群组成员身份。这不但包括提出请求的那一方，还可能包括接收数据的那方或者请求中介。

如图2所示，XACML的典型使用场景就是，某主体想对某个资源如文件系统或者Web服务器采取某种操作。该主体向该实体提交查询，以保护资源。该实体名为策略执行点（PEP）。PEP使用XACML请求语言生成请求。然后，PEP把该请求发送到策略决策点（PDP），它会检查请求、检索适用于该请求的策略（用SACML策略语言编写），然后根据评估策略的XACML规则，确定要不要授予访问权。这个响应（用XACML响应语言表示）返回给PEP，然后PEP允许或者拒绝请求方的访问。

XQuery和XML数据库实现SOA安全

安全标准和安全文档使用本文讨论的XML及各种XML标记语言来描述。XDMS是为SOA中的安全策略文档和安全消息添加持久性并进行查询的一种理想机制。如前面所述，XQuery可以用来从XML文档提取信息。XQuery基本上是一种函数式语言，它使用表达式作为装配查询的集中部分。每个查询可以描述成一组表达式，该表达式可以嵌套。这项主要特性使XQuery成为操纵XML处理的一种灵活、全面的方法。

为了有效地访问或者保存XML文档，用户需要XDMS。支持XQuery的XDMS能够迅速而方便地从XML安全文档检索信息。XML数据库已趋于成熟，可随时提供XML内容搜索和存储功能。

譬如说，XDMS能够维护不同版本的安全策略文档，为策略变更提供审查跟踪。此外，也可以为XML安全消息和请求添加持久性，提供SOA中所有安全事务的审查跟踪。(ccw)