ws-trust Archive

Webservice Security – WS-Trust and WS-SecureConversation an overview


“A Web Service is a system designed to support interoperable communication from machine to machine over a network. It includes an interface described in a machine-processable format (WSDL), and is typically conveyed using HTTP with XML serialization.”
Webservices exist in a wide range of architecture, technologies and software design. They provide an interaction mechanism between Business to Business applications. Webservices rely on SOAP Protocol for the interaction between the B2B applications. SOAP is and XML Based protocol that uses HTTP as its base transport protocol. Following is an example of a SOAP Request and SOAP Response




POST /SecureHelloWorldService/SecureHelloWorldService

HTTP/1.1 User-Agent: BEA WebLogic Server

Content-Type: text/xml; charset=utf-8 SOAPAction: “”


Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive Content-Length: 187


<env:Envelope xmlns:env=””>

<env:Header />


<m:sayHello xmlns:m=””>








HTTP/1.1 200 OK Date: Tue, 24 Jan 2012 06:15:42 GMT

Transfer-Encoding: chunked

Content-Type: text/xml; charset=utf-8

SOAPAction: “” X-Powered-By: Servlet/2.5 JSP/2.1




<env:Header />


<m:sayHelloResponse xmlns:m=””>

<m:return>Hello World</m:return>





Webservices Security

For a secure environment data exchange cannot happen in clear text as sensitive information might be exchanged. Also securing the communication channel for all communication is an overhead and might not be acceptable in all scenarios. Hence many specifications exist which allows to secure the data exchanged. One such framework is WS-Policy which defines how secure messages can be exchanged. To demonstrate this I have secured the above Webservice using standard policies and captured the SOAP Request and SOAP Response


@Policies({    @Policy(uri=”policy:Auth.xml”, direction=Policy.Direction.inbound),    @Policy(uri=”policy:Sign.xml”),    @Policy(uri=”policy:Encrypt.xml”)})


The message body is encrypted

<env:Body wsu:Id=”Body_FE10KgY262Y31ZRm” xmlns:wsu=””>

<ns1:EncryptedData Id=”3ZpXu9BlqgQNKF4s” Type=”” MimeType=”text/xml” Encoding=”UTF-8″ xmlns:ns1=””> <ns1:EncryptionMethod Algorithm=”” /> <ns1:CipherData> <ns1:CipherValue> T7MoCfhyDwXRjLrpRhZ62es3qK2jhTbY2ReS1ZSWhRaBidi8DwW5EbzNQKgudtPa8m7zxkW/ljebMV5dSvIZrJC1o+6peC111iFgPC4jMyA= </ns1:CipherValue>





In addition to this, security tokens need to be passed for authentication and authorization purpose.

Username Password Token

<wsse:UsernameToken wsu:Id=”unt_CQbnapvDgXSDnTtZ” xmlns:wsu=””> <wsse:Username>weblogic</wsse:Username>

<wsse:Password Type=””> weblogic </wsse:Password>



Binary Security Token

<wsse:BinarySecurityToken wsu:Id=”bst_MIWyV2RKFBlLh9AT”xmlns:wsu=””ValueType=”″EncodingType=””>MIICYTCCAgugAwIBAgIQsAtcv4jhs9Rpsu6m…..





Following is the lists of supported tokens that can be used for authentication and authorization purposes

Lists of tokens (Table 1)

Table 1

Token Type Description
User Name Token-Plain Carries basic information (username and a clear text password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.
Kerberos Token Carries basic information (username and, optionally, a password or shared secret), in a Kerberos token, for purposes of authenticating the user identity to the WSP.
X.509 Token Contains an X.509 formatted certificate for authentication using credentials created with a public key infrastructure (PKI). In this case, the WSC and WSP must trust each other’s public keys or share a common, trusted certificate authority.
SAML-Holder-Of-Key Token Uses the SAML holder-of-key confirmation method whereby the WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload. Can use either SAML v1.x or SAML v2.
SAML-Sender Vouches Token Uses the SAML sender-vouches confirmation method whereby the WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. Can use either SAML v1.x or SAML v2.


Key Exchange using WS-Trust

In the model above it’s the responsibility of the server to validate the tokens, signatures and perform authentication and authorization. This again can be an overhead, especially if the numbers of clients are very high. Also if the client is not known to the Service, it becomes difficult to establish a trust with the client. To address this situation WS-Trust standard has been adopted.  In this model, the responsibility of establishing the trust has been assigned to a third party. Clients request for a Security Token from a Secure Token Server (STS). Once they get the token, they present the token to the Service. The exchange mechanism and standard format of the token has been provided in WS-Trust specification.  In my test, I used opensso (an open source STS Server) and captured the request-response interaction as depicted in Figure below.


1)Client requests for a Security token to a Secure Token Server

<soap:Envelope  xmlns:wsa=””  xmlns:wsu=””  xmlns:wsse=””  xmlns:soap=””>

<soap:Header>      <wsa:To>http://demo</wsa:To>

<wsse:Security soap:mustUnderstand=”1″>  ….      </wsse:Security>    </soap:Header>    <soap:Body wsu:Id=”Id-d7fceab4-62ed-45fb-bc09-69310ff1712e”>      <wsse:RequestSecurityToken>        <wsse:TokenType>wsse:SecurityContextToken</wsse:TokenType>        <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>        <wsp:AppliesTo xmlns:wsp=””>          <wsa:EndpointReference>            <wsa:Address>http://localhost:7001//SecureHelloWorldService/SecureHelloWorldService</wsa:Address>          </wsa:EndpointReference>


</wsse:RequestSecurityToken>    </soap:Body>


2)Secure Token Server provides the token to the Client.

<soap:Envelope xmlns:wsa=””  xmlns:wsu=””  xmlns:wsse=””  xmlns:soap=””>

<soap:Header>      <wsse:Security soap:mustUnderstand=”1″> ….


</soap:Header>    <soap:Body wsu:Id=”Id-aa53632b-2211-46c8-451-4234b12ecf834″>

<xenc:EncryptedData xmlns:xenc=””>        <xenc:EncryptionMethod Algorithm=”” />        <xenc:CipherData>          <xenc:CipherValue>…




</soap:Body>  </soap:Envelope>

3)Using the token, the service is invoked.

<soap:Envelope xmlns:soap=””  xmlns:xsi=””  xmlns:xsd=””  xmlns:wsa=””  xmlns:wsu=””  xmlns:wsse=””>

<soap:Header>      <wsa:To>http://quoteservice</wsa:To>

<wsse:Security soap:mustUnderstand=”1″> ….      </wsse:Security>

</soap:Header>    <soap:Body wsu:Id=”Id-aa53632b-2211-46c8-451-4234b12ecf834″>

<xenc:EncryptedData xmlns:xenc=””> …

</xenc:EncryptedData>    </soap:Body>



4)Response from the service

<soap:Envelope xmlns:soap=””  xmlns:xsi=””  xmlns:xsd=””  xmlns:wsa=””  xmlns:wsu=””>    <soap:Header>    </soap:Header>    <soap:Body>       <m:sayHelloResponse xmlns:m=””>

<m:return>Hello World</m:return>       </m:sayHelloResponse>





1) Webservices Vulnerabilities, Security Compass Inc 2007
2) WS Trust Specification
3) WS Security Specification
4) Open SSO STS Solution