- 浏览: 316489 次
- 性别:
- 来自: 长沙
文章分类
最新评论
-
完善自我:
支持一下!
揭秘IT人才特点:中美印日四国程序员比较 -
悲剧了:
好文,看玩thinking in java的提到的异常处理,看 ...
高效的Java异常处理框架(转) -
yin_bp:
开源框架bbossgroups页支持组件异步方法调用哦,详情请 ...
Spring 3中异步方法调用 -
flyjava:
sun的悲哀
Apache怒了,威胁说要离开JCP
简介: WS-Security 为 SOAP 消息交换添加了企业级的安全特性,但却有大量的性能损失。WS-Trust 构建于 WS-Security 基础上,提供了一种交换安全令牌的方式,WS-SecureConversation 构建于 WS-Security 和 WS-Trust 基础上,改善了进行中的消息交换的性能。
WS-Security 构建于成熟的密码学以及 XML 加密及签名的行业标准基础上,为 Web 服务应用程序提供了一整套的安全特性。对于很多应用程序,WS-Security 的特性必不可少,但往往要以牺牲性能为代价。本系列之前的文章探讨了常见的 WS-Security 配置是如何影响主要的开源 Java™ Web 服务堆栈(Apache Axis2、Metro 和 Apache CXF)的性能的。
WS-Security 之所以常常伴随性能损失主要是因为大量使用了非对称加密。正如在 “Axis2 WS-Security 签名和加密” 一文中讨论的,非对称加密由于可处理密匙对,因此是一种很有用的工具。密匙对中的一个密匙被用来加密另一个密匙能够解密的消息。密匙对的所有者可以让一个密匙公开可用以便任何人都能使用它来加密发至此所有者的消息,并且还能解密来自此所有者的消息(由此验证发送者的身份)。非对称加密的一个劣势是与对称加密相比,它需要更大的密匙大小以及更多的处理负荷,因为对称加密基于的是只为此次交换中所涉各方所知的单个私密密匙。
关于本系列
Web 服务构成了 Java 技术在企业计算应用中的关键部分。在本系列文章中,XML 和 Web 服务顾问 Dennis Sosnoski 介绍了对于使用 Web 服务的 Java 开发人员来说比较重要的主要框架和技术。通过跟随本系列的学习,您将了解到该领域的最新进展,并且知道如何使用它们来为您的编程项目提供帮助。
WS-SecureConversation 是一种标准,允许对称加密被用于进行中的客户机和服务器之间的消息交换,从而消除了非对称加密增加的负荷。为了保障对称加密所需的私密密匙信息的安全交换,WS-SecureConversation 构建于 WS-Security 和另一种标准 WS-Trust 的基础上。WS-Trust 本身基于的是 WS-Security,定义了对发出并处理安全令牌的 Web 服务的接口。
WS-Trust 综合了两个相关函数。第一个函数是为了支持对安全令牌的处理 — 具体而言就是发出、更换以及取消安全令牌。第二个函数是为了支持中介信任关系。这两个函数看起来虽然不同,但它们之间是相互关联的,都要求安全令牌必须是可信的,并且信任也必须要以某种形式的令牌表示。
WS-Trust 的核心是一组用来发出、更换、取消以及验证安全令牌的消息。这些消息可以由客户机通过调用一种称为 Security Token Service(STS)的特定类型的 SOAP Web 服务进行交换。它们还可以以其他的方式传递(比如以对另外一个服务的请求的安全头部的形式)。
STS 是一种 Web 服务,可实现一个由 WS-Trust 规范定义的简单接口。这个接口允许客户机使用安全令牌提交对几种类型操作的请求。由于一个 STS 就是一种 Web 服务,因此 WS-Security 可被直接用在请求和响应消息内,而 WS-SecurityPolicy 则可被用来指定由客户机提供的凭证的类型或需要在消息上进行的其他的安全性处理。
最基本的一种操作是发出新令牌。清单 1 显示了为此目的而向一个 STS 发出一个示例请求,这个示例是经过编辑的,其中删除了各种头部,只列出请求主体。(稍后您将看到未删除头部的示例。)清单 1 所请求的是由 WS-SecureConversation 使用的一种称为 Security Context Token (SCT) 的特定令牌:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> ... </soap:Header> <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-7059772"> <wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <wst:RequestType>http://.../ws-sx/ws-trust/200512/Issue</wst:RequestType> <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>http://localhost:8800/cxf-seismicsc-signencr/</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsu:Created>2010-05-12T10:33:22.774Z</wsu:Created> <wsu:Expires>2010-05-12T10:38:22.774Z</wsu:Expires> </wst:Lifetime> <wst:TokenType >http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct</wst:TokenType> <wst:KeySize>128</wst:KeySize> <wst:Entropy> <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce" >kIYFB/u430k3PlOPfUtJ5A==</wst:BinarySecret> </wst:Entropy> <wst:ComputedKeyAlgorithm >http://.../ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm> </wst:RequestSecurityToken> </soap:Body> </soap:Envelope> |
清单 1 的请求主体显示了用于对 STS 的大多数请求的这个基本的 <wst:RequestSecurityToken>
元素。所需要的 <wst:RequestType>
子元素标识了此请求的特定类型,在本例中,为 Issue
请求。其余的子元素是 Issue
请求的一些可选参数,用来标识:
- 使用所请求的这个令牌能够访问的服务端点(
<wsp:AppliesTo>
元素) - 此令牌有效的时间区间(
<wst:Lifetime>
元素) - 令牌的类型(
<wst:TokenType>
元素) - 所请求的密匙的大小,单位为比特(
<wst:KeySize>
元素) - 由客户机提供的用来生成私密密匙的熵数据(
<wst:Entropy>
元素) - 用来生成私密密匙的算法(
<wst:ComputedKeyAlgorithm>
元素)
如果收到此请求的 STS 批准了全部所需的由客户机提供的凭证并同意了此请求的条款,那么它就会在对 Issue
请求的响应中返回一个安全令牌。清单 2 显示了成功响应 Issue
请求的一个例子,其中也删除了头部:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> ... </soap:Header> <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-4824957"> <wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <wst:RequestSecurityTokenResponse> <wst:RequestedSecurityToken> <wsc:SecurityContextToken xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="sctId-A167EB2B526E0894DA12736604029099"> <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier> </wsc:SecurityContextToken> </wst:RequestedSecurityToken> <wst:RequestedAttachedReference> <wsse:SecurityTokenReference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd" URI="#sctId-A167EB2B526E0894DA12736604029099" ValueType=".../ws-sx/ws-secureconversation/200512/sct"/> </wsse:SecurityTokenReference> </wst:RequestedAttachedReference> <wst:RequestedUnattachedReference> <wsse:SecurityTokenReference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd" URI="A167EB2B526E0894DA12736604029098" ValueType=".../ws-sx/ws-secureconversation/200512/sct"/> </wsse:SecurityTokenReference> </wst:RequestedUnattachedReference> <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsu:Created>2010-05-12T10:33:22.909Z</wsu:Created> <wsu:Expires>2010-05-12T10:38:22.909Z</wsu:Expires> </wst:Lifetime> <wst:RequestedProofToken> <wst:ComputedKey >http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKey> </wst:RequestedProofToken> <wst:Entropy> <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce" >DpkK6qcELTO8dlPdDHMi2A==</wst:BinarySecret> </wst:Entropy> </wst:RequestSecurityTokenResponse> </wst:RequestSecurityTokenResponseCollection> </soap:Body> </soap:Envelope> |
清单 2 中的响应显示了 <wst:RequestSecurityTokenResponseCollection>
元素包装了一个 <wst:RequestSecurityTokenResponse>
元素,而后者反过来又包装了这个响应令牌信息。由于此请求请求的是一个 SCT(如 清单 1 请求消息内的值
<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType> |
所示),因此此响应提供了:
- 这个实际的 SCT(包装于
<wst:RequestedSecurityToken>
元素内) - 一些引用结构(
<wst:RequestedAttachedReference>
和<wst:RequestedUnattachedReference>
) - 此令牌有效的时间区间(
<wst:Lifetime>
元素) - 一个 proof 令牌(
<wst:RequestedProofToken>
元素) - 由服务器提供的用来生成私密密匙的熵数据(
<wst:Entropy>
元素)
此 proof 令牌的内容定义了这个共享的秘密值以用作非对称加密的基础。在本例中,该共享的秘密值是通过使用一种确定的算法综合了由客户机和服务器提供的熵值生成的。
除了 Issue
请求类型外,还可以向 STS 做 Validate
、Renew
和 Cancel
请求。这些请求均需要之前已发出的令牌以便引用或提供。它们允许此客户机验证此令牌或者请求延长或终止此令牌的有效时间区间。
当只返回单一一个令牌时,来自 STS 的响应可以直接使用 <wst:RequestSecurityTokenResponse>
元素,而不用像 清单 2 所示的那样将其包装于 <wst:RequestSecurityTokenCollection>
元素内。对 STS 的请求则可以使用一个 <wst:RequestSecurityTokenCollection>
元素,该元素包装了任意数量的 <wst:RequestSecurityToken>
元素。
WS-Trust 还允许在 SOAP 消息头内直接传输安全令牌,而不是通过 STS Web 服务接口。如果令牌获取自一个与服务不在一处的 STS,那么这将是共享令牌的惟一方式。
WS-SecureConversation 构建于 WS-Trust 基础上,使用一个 STS 来管理 SCT。一个 SCT 代表的是在消息交换所涉各方之间共享的上下文,此共享上下文内的信息允许各方使用非对称加密来确保信息的安全。
特别地,此上下文向消息交换中所涉的各方提供了一个共享的秘密值(如 清单 2 响应消息内所示)。这个共享的秘密值本身可以是在交换过程中用来对消息进行非对称加密的密匙,但更建议的一种方式是使用这个共享秘密值作为获取交换中所需的实际私密密匙的基础值。这看起来虽然有点过于复杂,但却可以更好地难住那些监视消息交换并试图破译密匙的人。
WS-SecureConversation 在理论上可以用于多方的消息交换,但它最为常见的用法是用在一个客户机与一个服务器之间的通信。当用在这种配置中时,向客户机提供 SCT 的这个 STS 与此服务器位于一处,可在相同的端点地址访问到。这意味着服务器上的 Web 服务代码需要一种方式来辨别哪些消息是针对 STS 的,哪些消息是针对服务本身;用此请求上的这个动作可服务此目的。
图 1 展示了这种位于一处的 STS 配置以及消息交换:
图 1. 与服务位于一处的 WS-SecureConversation STS
当客户机想要开始与服务器交换消息时,它首先会联系此 STS 并建立上下文。此消息,如 图 1 中的消息 1 所示,指定了动作 http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
。此响应,消息 2,则向客户机提供了此 SCT。上下文在消息 3 中被引用,由它指定与实际的服务应用程序相关的任何动作。在此时间区间内,这个 SCT 在自此客户机至此服务的任何连续消息中均有效。消息 3 和 4 使用了基于共享秘密的对称加密,客户机和服务之间的所有后续消息也是如此。服务应用程序使用由此客户机提供的上下文引用来直接访问来自这个上下文(由 STS 保存的)的共享秘密。
WS-SecureConversation 使用的 WS-Policy 和 WS-SecurityPolicy 配置与本系列之前的文章中讨论的基本 WS-Security 处理所使用的配置相似。一个大的区别在于当使用 WS-SecureConversation 时,此策略必须涵盖两种不同的交换 — 即客户机与 STS 之间的交换以及客户机与实际的服务之间的交换。对于与 STS 之间的交换,可在策略描述中通过使用一个嵌套的策略加以处理,而此策略的主体则用于客户机与服务之间的交换。
清单 3 显示了用在本文的示例中的策略:
清单 3. 示例 WS-SecureConversation 策略
<wsp:Policy wsu:Id="SecConv" xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:ExactlyOne> <wsp:All> <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/> <sp:SymmetricBinding> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:SecureConversationToken sp:IncludeToken=".../AlwaysToRecipient"> <wsp:Policy> <sp:RequireDerivedKeys/> <sp:BootstrapPolicy> <wsp:Policy> <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient"> <wsp:Policy> <sp:RequireThumbprintReference/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken=".../IncludeToken/Never"> <wsp:Policy> <sp:RequireThumbprintReference/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:TripleDesRsa15/> </wsp:Policy> </sp:AlgorithmSuite> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts> <sp:Body/> <sp:Header Name="To" Namespace=".../addressing"/> <sp:Header Name="From" Namespace=".../addressing"/> <sp:Header Name="FaultTo" Namespace=".../addressing"/> <sp:Header Name="ReplyTo" Namespace=".../addressing"/> <sp:Header Name="MessageID" Namespace=".../addressing"/> <sp:Header Name="RelatesTo" Namespace=".../addressing"/> <sp:Header Name="Action" Namespace=".../addressing"/> </sp:SignedParts> <sp:Trust13> <wsp:Policy> <sp:MustSupportIssuedTokens/> <sp:RequireClientEntropy/> <sp:RequireServerEntropy/> </wsp:Policy> </sp:Trust13> </wsp:Policy> </sp:BootstrapPolicy> </wsp:Policy> </sp:SecureConversationToken> </wsp:Policy> </sp:ProtectionToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic128Rsa15/> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:SymmetricBinding> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> |
在 清单 3 中,外面的策略指定了使用对称加密(<sp:SymmetricBinding>
)来加密正在交换中的消息的主体(<sp:EncryptedParts>
设置,临近清单底部)。在对称加密策略内,<sp:ProtectionToken>
以及嵌套的 <sp:SecureConversationToken>
元素表明该 WS-SecureConversation 将被用来执行对称加密。
当 STS 被访问时应用的策略是由嵌套在 <sp:SecureConversationToken>
内的 <sp:BootstrapPolicy>
(如加粗部分所示)定义的。这个策略只指定了消息主体以及地址头的签名使用 X.509 证书,与本系列前期文章中使用的签名类型相同。
请注意,客户机与 STS 之间交换的消息在策略使用时,并未加密。这就使得我们更容易了解所发生的事情,但是对于实际使用,您可能想要使用 TLS/SSL 传输加密或者 WS-Security 加密来保护这次交换。
清单 4 显示了消息 1 和 2 的头部 — 分别为对 STS 的请求以及对客户机的响应。(在 清单 1 和 清单 2 中,您已经看到过这些消息的主体。)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Action xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32320445" >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action> <MessageID xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-2673180" >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</MessageID> <To xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-5132526" >http://localhost:8800/cxf-seismicsc-signencr/</To> ... <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"> <wsse:BinarySecurityToken xmlns:wsse="...wssecurity-secext-1.0.xsd" xmlns:wsu="...wssecurity-utility-1.0.xsd" EncodingType="...soap-message-security-1.0#Base64Binary" ValueType="...x509-token-profile-1.0#X509v3" wsu:Id="CertId-CF15C330C32618BF4912736604028486" >MIICo...8/0n33w==</wsse:BinarySecurityToken> <wsu:Timestamp xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-7"> <wsu:Created>2010-05-12T10:33:22.831Z</wsu:Created> <wsu:Expires>2010-05-12T10:38:22.831Z</wsu:Expires> </wsu:Timestamp> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8"> <ds:SignedInfo> ... <ds:Reference URI="#Id-7059772"> ... </ds:Reference> ... <ds:Reference URI="#Timestamp-7"> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>TYIbt...V0dd8=</ds:SignatureValue> <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604028487"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="STRId-CF15C330C32618BF4912736604028488"> <wsse:Reference xmlns:wsse="...wssecurity-secext-1.0.xsd" URI="#CertId-CF15C330C32618BF4912736604028486" ValueType="...x509-token-profile-1.0#X509v3"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body xmlns:wsu="..." wsu:Id="Id-7059772"> ... </soap:Body> </soap:Envelope> soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Action xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-33522601" >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT</Action> <MessageID xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-9229531" >urn:uuid:d9d1b9b2-a864-446b-ab81-3176f868046e</MessageID> <To xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-25551189" >http://www.w3.org/2005/08/addressing/anonymous</To> <RelatesTo xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32148925" >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</RelatesTo> <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"> <wsu:Timestamp xmlns:wsu= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-7"> <wsu:Created>2010-05-12T10:33:22.913Z</wsu:Created> <wsu:Expires>2010-05-12T10:38:22.913Z</wsu:Expires> </wsu:Timestamp> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8"> <ds:SignedInfo> ... <ds:Reference URI="#Id-4824957"> ... </ds:Reference> ... <ds:Reference URI="#Timestamp-7"> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>tr1tx...GY4wk=</ds:SignatureValue> <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040291811"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="STRId-A167EB2B526E0894DA127366040291812"> <wsse:KeyIdentifier EncodingType="...soap-message-security-1.0#Base64Binary" ValueType="...soap-message-security-1.1#ThumbprintSHA1" >uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-4824957"> ... </soap:Body> </soap:Envelope> |
在 清单 4 中,可以看到此证书从客户机发送到了服务器,并且此证书引用被返回给客户机,且每个方向上的证书被用来验证时间戳和消息主体的签名。对于这种策略配置,客户机证书需要受此 STS 信任,且此 STS 证书必须存在于此客户机的可信存储内。
清单 5 显示了使用了 WS-SecureConversation 的客户机与服务之间的消息交换(经大量编辑后的):
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Action xmlns="http://www.w3.org/2005/08/addressing">urn:matchQuakes</Action> <MessageID xmlns="http://www.w3.org/2005/08/addressing" >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</MessageID> ... <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"> <wsc:SecurityContextToken xmlns:wsc=".../ws-secureconversation/200512" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="sctId-A167EB2B526E0894DA12736604029099"> <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier> </wsc:SecurityContextToken> <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-9"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"> <wsse:Reference xmlns:wsse="..." URI="#sctId-A167EB2B526E0894DA12736604029099" ValueType="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct"/> </wsse:SecurityTokenReference> <wsc:Offset>0</wsc:Offset> <wsc:Length>16</wsc:Length> <wsc:Nonce>AyUGKYBNNQstD9EmZUJqlA==</wsc:Nonce> </wsc:DerivedKeyToken> <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512" xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-11"> ... </wsc:DerivedKeyToken> <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:DataReference URI="#EncDataId-12"/> </xenc:ReferenceList> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10"> <ds:SignedInfo> ... <ds:Reference URI="#Id-28812627"> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>6NHo8Si1ntZIb2Ivg3S/n1+2uzI=</ds:SignatureValue> <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604029689"> <wsse:SecurityTokenReference xmlns:wsse="..." xmlns:wsu="..." wsu:Id="STRId-CF15C330C32618BF49127366040296810"> <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-28812627"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"> <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>+krS8lGA...CKSN0fwKR36Q==</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soap:Body> </soap:Envelope> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Action xmlns="http://www.w3.org/2005/08/addressing" >http://ws.sosnoski.com/seismic/wsdl/SeismicInterface/quakeResponse</Action> <MessageID xmlns="http://www.w3.org/2005/08/addressing" >urn:uuid:c3aa0671-8751-4d6b-8d4c-0e37ce3e394a</MessageID> <To xmlns="http://www.w3.org/2005/08/addressing" >http://www.w3.org/2005/08/addressing/anonymous</To> <RelatesTo xmlns="http://www.w3.org/2005/08/addressing" >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</RelatesTo> <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"> <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512" ... </wsc:DerivedKeyToken> <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512" ... </wsc:DerivedKeyToken> <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:DataReference URI="#EncDataId-12"/> </xenc:ReferenceList> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10"> <ds:SignedInfo> ... <ds:Reference URI="#Id-10766816"> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>rU6YoV7BiO0qSQjWw2vwCp9R+fg=</ds:SignatureValue> <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040304813"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd" ...> <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-10766816"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"> <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>Cl0iUu...TJ6WkZl2A==</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soap:Body> </soap:Envelope> |
在 清单 5 中, SecurityContextToken
被包括于每个消息的头部,并由 <wsc:DerivedKeyToken>
元素引用,这些元素给出了获得实际用于签名并加密数据的那些私密密匙所需的参数。
至此,您已经了解了 WS-Trust 和 WS-SecureConversation 的基础知识,本系列的下一篇文章将会谈论 Apache Axis2、Metro 和 Apache CXF Web 服务堆栈上的 WS-SecureConversation 带来的性能益处。并且在获得此性能成果的过程中,您还将看到在这三个堆栈上配置 WS-SecureConversation 的细节。
<!-- CMA ID: 500749 --><!-- Site ID: 10 --><!-- XSLT stylesheet used to transform this file: dw-article-6.0-beta.xsl -->
学习
- “Using WS-Trust for token transformation”(Laurent Charles,developerWorks,2010 年 3 月):本文讨论了使用 WS-Trust 进行跨域的安全令牌交换。
-
了解 Web 服务规范:本系列教程介绍了许多重要的 Web 服务标准,包括:
- “了解 Web 服务规范: 第 2 部分:Web 服务描述语言 (WSDL)”(Nicholas Chase,developerWorks,2006 年 7 月)
- “了解 Web 服务规范: 第 4 部分:WS-Security”(Nicholas Chase,developerWorks,2006 年 8 月)
- “了解 Web 服务规范,第 5 部分: WS-Policy”(Tyler Anderson, developerWorks,2007 年 2 月)
-
OASIS Web Services Security (WSS) TC:该组织负责 WS-Security 规范和令牌配置文件。您可以从这里找到这些标准的所有版本的链接。
-
W3C Web Services Policy Working Group:该工作组定义了 WS-Policy 规范。
-
OASIS Web Services Secure Exchange (WS-SX) TC:该组织负责 WS-SecurityPolicy、WS-SecureConversation 和 WS-Trust。
- 浏览 技术书店,阅读关于这些和其他技术主题的图书。
- developerWorks Java 技术专区:这里有数百篇关于 Java 编程各个方面的文章。
原文:http://www.ibm.com/developerworks/cn/java/j-jws15/
发表评论
-
WS-I闭关,这对WS-*意味着什么?
2010-11-15 21:19 950观点 :Web Services互操作组织(WS-I) 刚 ... -
EDA 和 SOA 的融合以及实践
2010-11-08 09:55 1036EDA 和 SOA SOA 简介 ... -
REST vs. SOAP
2010-11-04 17:08 1790看起来在web API协议之争(如果曾经有过)中,潮流正稳步的 ... -
SOA分析和设计中的错误处理要点
2010-10-24 23:51 1078在SOA分析和设计阶段进行全面的错误处理需求分析对于正确完成设 ... -
WebSphere Message Broker 开发和部署最佳实践
2010-10-23 18:24 2323简介: 本文以多个客户企业的经验为基础,给出了使用 Web ... -
带附件的 SOAP 消息
2010-09-30 15:16 1315简介: 本 文介绍了一种在 MIME Multipa ... -
利用 Geronimo 2.2 创建安全的 Web Service 应用
2010-09-30 14:49 1017简介: 随着 Web Service ... -
大学内的云计算解决方案
2010-09-29 14:16 1728本文通过使用一个 Virtual Computing Lab ... -
整合 WebSphere ILOG JRules 与 IBM Content Manager Enterprise Edition
2010-09-28 10:30 2193简介: 自动决策在内 ... -
评估企业是否适合开发复合业务服务
2010-09-27 17:01 1064本文介绍如何评估一个 ... -
集成 IBM 元数据存储库,第 2 部分: 在 WebSphere Service Registry and Repository 中治理元数据生命周期
2010-09-27 16:55 1094通过将您的应用程序与 IBM® Rational® Asset ... -
集成 IBM 元数据存储库,第 1 部: APIs for accessing Rational Asset Manager
2010-09-27 16:52 960通过将您的应用程序与 IBM® Rational® Asset ... -
不使用客户端证书的 WS-Security
2010-09-27 15:42 1344许多 WS-Security 配置要 ... -
CXF 性能比较
2010-09-27 15:15 1679Apache CXF Web 服务栈建立在与本系列早期文章讨论 ... -
通过 CXF 使用 WS-Security
2010-09-27 15:11 2775与 本系列 前面的文章 ... -
CXF 简介
2010-09-27 15:07 4341Apache CXF Web 服务堆栈是来自 Apache ... -
比较 Metro 与 Axis2 性能
2010-09-27 15:04 1135Metro Web 服务堆栈是基于 ... -
Metro 服务下的 WS-Security
2010-09-27 15:00 1303本文展示如何通过 Metro 来使用和配置 WS-Securi ... -
Metro 简介
2010-09-27 14:52 1984Metro Web 服务栈是由 Sun M ... -
Axis2 中的 JAXB 和 JAX-WS
2010-09-27 10:38 1706早期的 Apache Axis 建立在第一个面向 Web 服务 ...
相关推荐
此外,WS-Security家族还包括了WS-SecureConversation、WS-Federation、WS-Authorization、WS-Policy、WS-Trust和WS-Privacy等一系列子规范,这些规范共同构建了一个完整的Web Service安全框架,以满足不同场景下的...
它不仅支持标准的服务协议和技术栈,还提供了工具和服务来帮助开发者构建、部署和管理基于 SOA 的应用。 - **Web 服务在 SOA 中的角色**:Web 服务是实现 SOA 的核心技术之一。它们通过标准协议(如 SOAP、HTTP 等)...
实现Web服务通常涉及创建WSDL文件、编写服务端代码(如Java的JAX-WS或.NET的WCF)和部署服务。在客户端,开发者可以使用工具自动生成代理类来调用服务。例如,Java中的JAX-WS提供了wsimport工具,.NET中的svcutil....
- **JAX-WS**(Java API for XML Web Services):Java平台上的Web服务标准,用于创建和消费SOAP Web服务。 - **.NET Framework**:微软提供的开发环境,支持创建和使用Web服务,包括WCF(Windows Communication ...
WSE3.0是针对WSE2.0的升级版本,主要目的是为了更好地支持基于WS-*标准的Web服务,这些标准包括WS-Security、WS-Trust、WS-SecureConversation和WS-Addressing等。 在开始学习WSE3.0之前,我们需要理解Web服务的...
该规范描述了如何在Web服务环境中建立企业间的信任关系,支持安全的令牌交换和服务授权。 **2. WS-Privacy** 该规范描述了如何将隐私政策及偏好与Web服务相关联,确保数据处理过程中尊重用户的隐私。 **3. WS-...
- **UDDI 2.0**:解释了 Universal Description, Discovery, and Integration(UDDI)版本 2.0 如何帮助企业和服务提供商发现彼此并相互交换服务信息。 - **JAX-R 1.0**:探讨了 Java API for XML Registries(JAX-R...
Web服务(Web Services)是一种基于互联网的、使用标准XML(Extensible Markup Language)进行通信的软件系统,允许不同平台的应用程序之间交换数据和服务。在Web服务的安全性规范分析与研究中,我们需要关注多个...
10. **安全协议栈**:WS-SecureConversation和WS-Trust等协议提供了安全会话管理和信任建立的机制,允许在多个消息之间维持安全上下文。 综上所述,Web Services的安全机制涉及多个层面,从身份验证、加密、完整性...
综上所述,“apache-cxf-3.4.4”是一个功能丰富的Web服务框架,它不仅简化了Web服务的开发过程,还提供了广泛的支持和服务,包括代码生成、客户端调用、安全机制以及与其他框架的集成,是Java开发人员构建Web服务的...
6. **安全特性**:CXF包含了对WS-Security、WS-Trust、WS-SecureConversation等安全标准的支持,帮助开发者构建安全的Web服务。 7. **传输和编码**:CXF支持多种传输方式,如HTTP、HTTPS、JMS等,以及各种编码方式...
管理规格包括了监控和服务管理等方面的标准。 - **WS-Notification**: 一种通知机制,用于实时通知事件的发生。 - **WS-Eventing**: 规定了如何订阅、发布和取消订阅事件。 - **WS-Management**: 提供了一个统一的...
2. **WS-安全组件**:实现了WS-Security、WS-Trust、WS-SecureConversation等规范,为Web服务提供安全特性,如身份验证、加密和消息完整性。 3. **WS-地址和事务组件**:支持WS-Addressing和WS-Transaction,允许...
1. **CXF配置**:项目可能包含了CXF的配置文件,如`cxf.xml`或`spring-servlet.xml`,这些文件用于设置CXF的端点、拦截器和服务行为,以启用WS-Security。 2. **WS-Security配置**:在配置文件中,会配置WS-...
它包括WS-SecureConversation、WS-Trust、WS-Federation等子标准,可以支持消息完整性、消息加密和单点登录等功能。 9. Ws-Addressing:Ws-Addressing是一种SOAP消息头的规范,用于在消息中指定SOAP消息的目的地和...
WS-SecureConversation, and WS-Trust. Frontends: CXF supports a variety of "frontend" programming models. CXF implements the JAX-WS APIs. It also includes a "simple frontend" which allows creation of ...
- **WS-Security**:支持Web服务安全标准,如WS-SecureConversation和WS-Trust,确保服务的安全性。 - **数据绑定**:CXF支持多种数据绑定机制,如JAXB、Aegis等,方便处理XML和Java对象之间的转换。 - **MTOM/XOP**...