WS-Security构建于成熟的密码学以及 XML 加密及签名的行业标准基础上，为Web服务应用程序提供了一整套的安全特性。对于很多应用程序，WS-Security的特性必不可少，但往往要以牺牲性能为代价。

　　WS-Security之所以常常伴随性能损失主要是因为大量使用了非对称加密。正如在 “Axis2 WS-Security签名和加密” 一文中讨论的，非对称加密由于可处理密匙对，因此是一种很有用的工具。密匙对中的一个密匙被用来加密另一个密匙能够解密的消息。密匙对的所有者可以让一个密匙公开可用以便任何人都能使用它来加密发至此所有者的消息，并且还能解密来自此所有者的消息（由此验证发送者的身份）。非对称加密的一个劣势是与对称加密相比，它需要更大的密匙大小以及更多的处理负荷，因为对称加密基于的是只为此次交换中所涉各方所知的单个私密密匙。

　　WS-SecureConversation是一种标准，允许对称加密被用于进行中的客户机和服务器之间的消息交换，从而消除了非对称加密增加的负荷。为了保障对称加密所需的私密密匙信息的安全交换，WS-SecureConversation构建于WS-Security和另一种标准WS-Trust的基础上。WS-Trust本身基于的是 WS-Security，定义了对发出并处理安全令牌的Web服务的接口。

　　WS-Trust

　　WS-Trust综合了两个相关函数。第一个函数是为了支持对安全令牌的处理 — 具体而言就是发出、更换以及取消安全令牌。第二个函数是为了支持中介信任关系。这两个函数看起来虽然不同，但它们之间是相互关联的，都要求安全令牌必须是可信的，并且信任也必须要以某种形式的令牌表示。

　　WS-Trust的核心是一组用来发出、更换、取消以及验证安全令牌的消息。这些消息可以由客户机通过调用一种称为Security Token Service（STS）的特定类型的SOAP Web服务进行交换。它们还可以以其他的方式传递（比如以对另外一个服务的请求的安全头部的形式）。

　　STS的基础知识

　　STS是一种Web服务，可实现一个由WS-Trust规范定义的简单接口。这个接口允许客户机使用安全令牌提交对几种类型操作的请求。由于一个STS就是一种Web服务，因此WS-Security可被直接用在请求和响应消息内，而WS-SecurityPolicy则可被用来指定由客户机提供的凭证的类型或需要在消息上进行的其他的安全性处理。

　　最基本的一种操作是发出新令牌。清单 1 显示了为此目的而向一个STS发出一个示例请求，这个示例是经过编辑的，其中删除了各种头部，只列出请求主体。（稍后您将看到未删除头部的示例。）清单 1 所请求的是由WS-SecureConversation使用的一种称为Security Context Token (SCT)的特定令牌：

　　清单 1. 向STS请求一个安全令牌
    

以下是引用片段： <soap:Envelope >   <soap:Header>     …   </soap:Header>   <soap:Body        wsu:Id=”Id-7059772″>     <wst:RequestSecurityToken         >       <wst:RequestType>http://…/ws-sx/ws-trust/200512/Issue</wst:RequestType>       <wsp:AppliesTo >         <wsa:EndpointReference >           <wsa:Address>http://localhost:8800/cxf-seismicsc-signencr/</wsa:Address>         </wsa:EndpointReference>       </wsp:AppliesTo>       <wst:Lifetime >         <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请求的一个例子，其中也删除了头部：

　　清单 2. 以来自STS的安全令牌进行响应
    

以下是引用片段： <soap:Envelope >   <soap:Header>     …   </soap:Header>   <soap:Body        wsu:Id=”Id-4824957″>     <wst:RequestSecurityTokenResponseCollection         >       <wst:RequestSecurityTokenResponse>         <wst:RequestedSecurityToken>           <wsc:SecurityContextToken                                             wsu:Id=”sctId-A167EB2B526E0894DA12736604029099″>             <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>           </wsc:SecurityContextToken>         </wst:RequestedSecurityToken>         <wst:RequestedAttachedReference>           <wsse:SecurityTokenReference             >             <wsse:Reference                  URI=”#sctId-A167EB2B526E0894DA12736604029099″                 ValueType=”…/ws-sx/ws-secureconversation/200512/sct”/>           </wsse:SecurityTokenReference>         </wst:RequestedAttachedReference>         <wst:RequestedUnattachedReference>           <wsse:SecurityTokenReference             >             <wsse:Reference              URI=”A167EB2B526E0894DA12736604029098″             ValueType=”…/ws-sx/ws-secureconversation/200512/sct”/>           </wsse:SecurityTokenReference>         </wst:RequestedUnattachedReference>         <wst:Lifetime >           <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-SecureConversation构建于WS-Trust基础上，使用一个STS来管理SCT。一个SCT代表的是在消息交换所涉各方之间共享的上下文，此共享上下文内的信息允许各方使用非对称加密来确保信息的安全。

　　特别地，此上下文向消息交换中所涉的各方提供了一个共享的秘密值（如 清单 2 响应消息内所示）。这个共享的秘密值本身可以是在交换过程中用来对消息进行非对称加密的密匙，但更建议的一种方式是使用这个共享秘密值作为获取交换中所需的实际私密密匙的基础值。这看起来虽然有点过于复杂，但却可以更好地难住那些监视消息交换并试图破译密匙的人。

　　STS和服务

　　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-Policy 配置

　　WS-SecureConversation使用的WS-Policy和WS-SecurityPolicy配置与本系列之前的文章中讨论的基本WS-Security处理所使用的配置相似。一个大的区别在于当使用WS-SecureConversation时，此策略必须涵盖两种不同的交换 — 即客户机与STS之间的交换以及客户机与实际的服务之间的交换。对于与STS之间的交换，可在策略描述中通过使用一个嵌套的策略加以处理，而此策略的主体则用于客户机与服务之间的交换。

　　清单 3 显示了用在本文的示例中的策略：

　　清单 3. 示例WS-SecureConversation策略    
 

以下是引用片段： <wsp:Policy wsu:Id=”SecConv”               >   <wsp:ExactlyOne>     <wsp:All>       <wsap:UsingAddressing />       <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 中，您已经看到过这些消息的主体。）

　　清单 4. STS请求和响应的头部
    

以下是引用片段： <soap:Envelope >   <soap:Header>     <Action         wsu:Id=”Id-32320445″       >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action>     <MessageID         wsu:Id=”Id-2673180″       >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</MessageID>     <To         wsu:Id=”Id-5132526″       >http://localhost:8800/cxf-seismicsc-signencr/</To>     …     <wsse:Security  soap:mustUnderstand=”1″>       <wsse:BinarySecurityToken                   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  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  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                           wsu:Id=”STRId-CF15C330C32618BF4912736604028488″>             <wsse:Reference              URI=”#CertId-CF15C330C32618BF4912736604028486″             ValueType=”…x509-token-profile-1.0#X509v3″/>           </wsse:SecurityTokenReference>         </ds:KeyInfo>       </ds:Signature>     </wsse:Security>   </soap:Header>   <soap:Body  wsu:Id=”Id-7059772″>     …   </soap:Body> </soap:Envelope> soap:Envelope >   <soap:Header>     <Action         wsu:Id=”Id-33522601″       >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT</Action>     <MessageID         wsu:Id=”Id-9229531″       >urn:uuid:d9d1b9b2-a864-446b-ab81-3176f868046e</MessageID>     <To         wsu:Id=”Id-25551189″       >http://www.w3.org/2005/08/addressing/anonymous</To>     <RelatesTo         wsu:Id=”Id-32148925″       >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</RelatesTo>     <wsse:Security  soap:mustUnderstand=”1″>       <wsu:Timestamp >         <wsu:Created>2010-05-12T10:33:22.913Z</wsu:Created>         <wsu:Expires>2010-05-12T10:38:22.913Z</wsu:Expires>       </wsu:Timestamp>       <ds:Signature  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                           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  wsu:Id=”Id-4824957″>     …   </soap:Body> </soap:Envelope>

 
　　在 清单 4 中，可以看到此证书从客户机发送到了服务器，并且此证书引用被返回给客户机，且每个方向上的证书被用来验证时间戳和消息主体的签名。对于这种策略配置，客户机证书需要受此STS信任，且此STS证书必须存在于此客户机的可信存储内。

　　清单 5 显示了使用了WS-SecureConversation的客户机与服务之间的消息交换（经大量编辑后的）：

　　清单 5. 对服务的请求以及对客户机的响应
    

以下是引用片段： <soap:Envelope >   <soap:Header>     <Action >urn:matchQuakes</Action>     <MessageID        >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</MessageID>     …     <wsse:Security  soap:mustUnderstand=”1″>       <wsc:SecurityContextToken                   wsu:Id=”sctId-A167EB2B526E0894DA12736604029099″>         <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>       </wsc:SecurityContextToken>       <wsc:DerivedKeyToken           wsu:Id=”derivedKeyId-9″>         <wsse:SecurityTokenReference >           <wsse:Reference  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           wsu:Id=”derivedKeyId-11″>         …       </wsc:DerivedKeyToken>       <xenc:ReferenceList >         <xenc:DataReference URI=”#EncDataId-12″/>       </xenc:ReferenceList>       <ds:Signature  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             wsu:Id=”STRId-CF15C330C32618BF49127366040296810″>             <wsse:Reference  URI=”#derivedKeyId-9″/>           </wsse:SecurityTokenReference>         </ds:KeyInfo>       </ds:Signature>     </wsse:Security>   </soap:Header>   <soap:Body  wsu:Id=”Id-28812627″>     <xenc:EncryptedData  …>       <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes128-cbc”/>       <ds:KeyInfo >         <wsse:SecurityTokenReference >           <wsse:Reference  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 >   <soap:Header>     <Action        >http://ws.sosnoski.com/seismic/wsdl/SeismicInterface/quakeResponse</Action>     <MessageID        >urn:uuid:c3aa0671-8751-4d6b-8d4c-0e37ce3e394a</MessageID>     <To        >http://www.w3.org/2005/08/addressing/anonymous</To>     <RelatesTo        >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</RelatesTo>     <wsse:Security  soap:mustUnderstand=”1″>       <wsc:DerivedKeyToken        …       </wsc:DerivedKeyToken>       <wsc:DerivedKeyToken        …       </wsc:DerivedKeyToken>       <xenc:ReferenceList >         <xenc:DataReference URI=”#EncDataId-12″/>       </xenc:ReferenceList>       <ds:Signature  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  …>             <wsse:Reference  URI=”#derivedKeyId-9″/>           </wsse:SecurityTokenReference>         </ds:KeyInfo>       </ds:Signature>     </wsse:Security>   </soap:Header>   <soap:Body  wsu:Id=”Id-10766816″>     <xenc:EncryptedData  …>       <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes128-cbc”/>       <ds:KeyInfo >         <wsse:SecurityTokenReference >           <wsse:Reference  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的细节。