dev2dev: WS-Security and Java: Practical, In-Depth, Message-Based Security

Web services security (WS-Security) specification has been out for more than a year now. However, the real life implementation of the technology has followed a slow pace, attempting to map the footsteps of Web services development. This session will present the WS-Security implementations currently in the Java community, as well as the trends and standardization in process. It provides a quick introduction to the various aspects of WS-Security, including the use and significance of key WS-Security concepts such as tokens, XML encryption, canonicalization, XML signature, and policy. It will briefly touch upon related security standards such as SAML, XACML, XrMS, Kerberos and XKMS, and other important aspects of Web services security such as single sign-on, federation and secure conversation. This paper will then provide examples of implementations of WS-Security by Web service tool vendors such as Apache AXIS, BEA WebLogic, IBM WebSphere, and Microsoft .NET. Detailed comparisons will be made with real-life demonstrations of interoperability between these platforms using WS-Security-enabled Web services.

In the end you will see a real-world, practical application of Web services security using the current state of Java technology. In addition, you will gain an understanding of where WS-Security is moving, and understand the issues that will be met when implementing a strong WS-Security solution in Java.

Download the author's files associated with this article

WS-Security:

The most significant barrier to Web services is end-to-end security. WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys.

In short, the goal of WS-Security is to enable applications to construct secure SOAP message exchanges and to achieve end-to-end message-level security and not just transport-level security.

Tokens:

Security Token - A security token represents a collection of claims where a claim is a declaration that an entity makes (e.g. name, identity, key, group, privilege, capability, etc).

Signed Security Token - A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket).

There are two kinds of tokens:

Unsigned Security Token (ex: Username)
Signed Security Token (ex: x.509 certificates, Kerberos ticket)

Figure 1.1

According to Oasis specification, an example of a SOAP message with a username token is given below:

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
   <S:Header>
            ...
       <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>WebLogic</wsse:Username>
                <wsse:Password>WebLogic</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
            ...
    </S:Header>
    ...         
</S:Envelope>

BEA WebLogic Workshop Sample: UserName Token

An example of a WSSE policy file used by Workshop Web service is given below. The policy defines that each incoming SOAP message must be accompanied by a username and password and outgoing SOAP messages should be accompanied by a username and password before sending them out on the wire.

<?xml version="1.0" ?> 
<wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd"
    xmlns="http://www.bea.com/2003/03/wsse/config"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <!--
    Incoming SOAP messages must be accompanied by a username and password.
    -->
<wsSecurityIn>
            <token tokenType="username"/>
</wsSecurityIn>
    <!--
    Accompany outgoing SOAP messages with a username and password before sending them
    out on the wire.
    -->
<wsSecurityOut>
            <userNameToken>
                  <userName>weblogic</userName>
                  <password type="TEXT">weblogic</password>
</userNameToken>
</wsSecurityOut>
</wsSecurityPolicy>

The following example illustrates the use of BinarySecurityToken:

<wsse:BinarySecurityToken
             xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" 
             Id="myBinaryToken"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgZsDer9IQEmtJZc0...
  </wsse:BinarySecurityToken>

XML Signatures:

XML signatures are used to authenticate the identity of the sender and to ensure the integrity of SOAP messages. If any part of an incoming SOAP message has been changed in transport, the signature validation performed by the recipient will fail.

WS-Security specification allows for multiple signatures to be attached to a message, each referencing different, even overlapping, parts of the message. This is important for many distributed applications where messages flow through multiple processing stages.

BEA WebLogic Workshop Sample: XML signatures for incoming and outgoing SOAP messages

WSSE policy file contents:

<wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd"xmlns="http://www.bea.com/2003/03/wsse/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <wsSecurityIn>
        <!--
        Incoming SOAP messages must be digitally signed with the sender's
        private key. 
        The sender's public key is used to validate the signature.
        -->
                <signatureRequired>true</signatureRequired>
        </wsSecurityIn>
    <wsSecurityOut>
        <!--
        Sign the SOAP message with the sender's private key. Only the sender's public 
  key can validate the signature. Ensures the authenticity of the sender, i.e., that the sender is 
        in fact the source of the SOAP message.   
        -->
       <signatureKey>
                <alias>mycompany</alias>
                <password>password</password>
         </signatureKey>
    </wsSecurityOut>
    <!--
Look for the sender's.jks keystore in the default location, the server domain root, in this case,
BEA_HOME\WebLogic81\samples\domains\workshop.
    -->      
    <keyStore>
                <keyStoreLocation>samples_sender.jks</keyStoreLocation>
                <keyStorePassword>password</keyStorePassword>
        </keyStore>
</wsSecurityPolicy>

XML Encryption:

The specification allows encryption of any combination of body blocks, header blocks, any of these sub-structures, and attachments by either a common symmetric key shared by the sender and the receiver or a key carried in the message in an encrypted form.

Why Encryption?

Consider the following fictitious payment information, which includes identification information and information appropriate to a payment method (e.g., credit card, money transfer, or electronic check):

 <?xml version='1.0'?>
   <PaymentInfo xmlns='http://example.org/paymentv2'>
     <Name>John Smith </Name>
     <CreditCard Limit='5,000' Currency='USD'>
       <Number>4019 2445 0277 5567 </Number>
      <Issuer>Example Bank </Issuer>
      <Expiration>04/02 </Expiration>
     </CreditCard>
   </PaymentInfo>

This markup indicates that John Smith is using his credit card with a limit of $5,000USD.

Encrypting an XML Element:

Smith's credit card number is sensitive information. If the application wishes to keep that information confidential, it can encrypt the CreditCard element:

  <?xml version='1.0'?>
  <PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <CipherData>
        <CipherValue>A23B45C56</CipherValue>
      </CipherData>
    </EncryptedData>
  </PaymentInfo>

By encrypting the entire CreditCard element from its start to end tags, the identity of the element itself is hidden. (An eavesdropper doesn't know whether he used a credit card or money transfer.) The CipherData element contains the encrypted serialization of the CreditCard element.

BEA WebLogic Workshop Sample: XML Encryption for incoming and outgoing SOAP messages

WSSE policy file contents:

<wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd" 
xmlns="http://www.bea.com/2003/03/wsse/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <wsSecurityOut>
        <!--
Encrypt the SOAP message with the recipient's public key. Only the recipient's private key can decrypt it. 
Ensures the confidentiality of the SOAP message. (This process requires that the sender's keystore already 
contain a digital certificate containing the recipient's public key.)  
        -->
           <encryption>
                <encryptionKey>
                        <alias>mycompany</alias>
                </encryptionKey>
           </encryption>  
        </wsSecurityOut>
       
        <wsSecurityIn>
                <!--Incoming SOAP messages must be encrypted with client's public key. The alias and 
                password to access the client's decrypting private key in the keystore are provided by the
                <decryptionKey> element below.       -->
                <encryptionRequired>
                        <decryptionKey>
                                <alias>client1</alias>
                                <password>password</password>
                        </decryptionKey>
                </encryptionRequired> 
    </wsSecurityIn>
 
      <!--
      Look for the client.jks keystore in the default location, the server domain 
      root, in this case, BEA_HOME\WebLogic81\samples\domains\workshop.
      -->    
        <keyStore>
        <keyStoreLocation>samples_client.jks</keyStoreLocation>
        <keyStorePassword>password</keyStorePassword>
    <</keyStore>
</wsSecurityPolicy>

Algorithms:

The following table outlines additional algorithms that WS-Security recommends:

Algorithm Type	Algorithm	Algorithm URI
Canonicalization	Exclusive XML Canonicalization	http://www.w3.org/2001/10/xml-exc-c14n
Transformations	XML Decryption Transformation	http://www.w3.org/2001/04/decrypt

The Exclusive XML Canonicalization algorithm addresses the pitfalls of general canonicalization that can occur from leaky namespaces with pre-existing signatures.

Finally, if a sender wishes to sign a message before encryption, the sender should use the Decryption Transformation for XML signature.

Security Requirements vs. Technologies:

Authentication: Username/password, key-based digital signature and verification, smart cards, etc.
Authorization:Application of policy, access control
Auditing Various: forms of logging, themselves secured to avoid tampering
Non-repudiation:Key-based digital signing and signature verification
Integrity :Key-based digital signing and signature verification, message reliability
Confidentiality: Key-based encryption and decryption
Trust: Key-based digital signing and signature verification, message reliability

XML-Based Security Infrastructure:

SAML:
SAML is an open framework for sharing security information on the Internet through XML documents:

A SAML assertion makes statements about a subject (an individual or a service)
Three kinds of SAML assertions: authentication, attribute, authorization
SAML assertions can be digitally signed
Assertions are issued by "authorities"

Authentication SAML Assertion Example:
SAML assertions are attached to SOAP messages using WS-Security by placing assertion elements inside the <wsse:Security> header. The following example illustrates a SOAP message with a SAML assertion token:

<saml:Assertation MajorVersion="1" MinorVersion="0" 
AssertionID="186CB370-5C81-4716-8F65-F0B4FC4B4A0B" 
Issuer="www.test.com" IssueInstant="2001-05-31T13:20:00-05:00"> 
     <saml:Conditions NotBefore="2001-05-31T13:20:00-05:00" NotAfter="2001-05-31T13:25:00-05:00"/> 
         <saml:AuthenticationStatement AuthenticationMethod="password" 
AuthenticationInstant="2001-05-31T13:21:00-05:00"> 
          <saml:Subject> 
             <saml:NameIdentifier> 
               <SecurityDomain>"www.example.com"</SecurityDomain> 
               <Name>"cn=Alice,co=example,ou=sales"</Name> 
            </saml:NameIdentifier> 
         </saml:Subject>
      </saml:AuthenticationStatement> 
</saml:Assertion>

SAML Response Example:

<samlp:Response MajorVersion="1" MinorVersion="0" RequestID="186CD370-181-4236-8F65-
              F0B4FC4B4A0B" InResponseTo="EE52CAF4-3452-4ebe-84D3-4D372C892A5D"   
              StatusCode="Success"> 
    <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="186CD370-5C81-4716-8F65-
              F0B4FC4B4A0B" Issuer="www.test.com"> 
       <saml:Conditions NotBefore="2001-05-31T13:20:00-05:00" 
                NotAfter="2001-05-31T13:25:00-05:00"/> 
       <saml:AuthorizationDecisionStatement/> 
    </saml:Assertion> 
</samlp:Request>

XACML:

Extensible Access Control Markup Language (XACML) is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML). The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed, and interpret the result. The response would be one of the four values: permit, deny, indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or not applicable (the request can't be answered by this service).

XACML provides for fine-grained control of activities (such as read, write, copy, delete) based on several criteria, including the following:

Attributes of the user requesting access (e.g., "Only division managers and above can view this document.")
The protocol over which the request is made (e.g., "This data can be viewed only if it is accessed over HTTPS.")
The authentication mechanism (e.g., "The requester must have been authenticated using a digital device.")

An XACML policy consists of header information, an optional text description of the policy, a target, one or more rules, and an optional set of obligations.

Example of a XACML request:

<?xml version="1.0" encoding="UTF-8"?>
 <Request
    xmlns="urn:oasis:names:tc:xacml:1.0:context"xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
     http://www.oasis-open.org/tc/xacml/1.0/sc-xacml-schema-context-01.xsd">
   <Subject>
         <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"   
                         DataType="identifier:rfc822name">
          <AttributeValue>bs@simpsons.com</AttributeValue>
     </Attribute>
   </Subject>
   <Resource>
     <Attribute AttributeId="identifier:resource:resource-uri" DataType="xs:anyURI">
       <AttributeValue>http://medico.com/record/patient/BartSimpson</AttributeValue>
     </Attribute>
   </Resource>
   <Action>
     <Attribute AttributeId="identifier:action:action-id" DataType="xs:string">
       <AttributeValue>read</AttributeValue>
     </Attribute>
   </Action>
</Request>

Example of a XACML response:

<?xml version="1.0" encoding="UTF-8"?>
 <Response
     xmlns="urn:oasis:names:tc:xacml:1.0:context"
     xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
         http://www.oasis-open.org/tc/xacml/1.0/sc-xacml-schema-context-01.xsd">
  <Result>
     <Decision>Deny</Decision>
   </Result>
</Response>

XrML:

Extensible Rule Markup Language (XRML) is a general-purpose, XML-based specification grammar for expressing rights and conditions associated with digital content, services, or any digital resource.

The following example illustrates a message with an XML signature that references an XRML token.

<S:Envelope xmlns:S="...">
    <S:Header>
        <wsse:Security xmlns:wsse="...">
            <xrml:license xmlns:xrml="..."
                          licenseId="urn:SecurityToken-ef375268"/>
                ...
            </xrml:license>
            <ds:Signature xmlns:ds="...">
                ...
                <ds:KeyInfo>
                   <wsse:SecurityTokenReference>
                     <wsse:Reference URI="urn:SecurityToken-ef375268"
                                     xmltok:RefType="xrml:license"
                                     xmlns:xmltok="..."/>
                   </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
            ...
        </wsse:Security>
    </S:Header>
    <S:Body>
        ...
    </S:Body>
</S:Envelope>

Kerberos:

Kerberos is an established authentication and security infrastructure. Integration with Web services security requires the following actions:

Requesting and issuing security tokens
Attaching security token to messages
Establishing a secure context
Signing and encrypting the message using the security context

The following sample message illustrates signing using a Kerberos token:

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope">
<S:Header> ...
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/07/secext">
<wsse:BinarySecurityToken id="Kerberosv5ST" wsse:ValueType="wsse:Kerberosv5ST"
        wsse:EncodingType="wsse:Base64Binary">
                MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-excc14n#"/>
<ds:SignatureMethod
Algorithm="...#DES-MD5"/> ………….

Federations:

A federation is a collection of realms/domains that have established trust. The level of trust may vary, but it typically includes authentication and may include authorization.

Federations provide a simple, flexible mechanism to identify and validate users from partner organizations and provide them with seamless access to Web sites within that trusted federation without requiring re-authentication. In addition, federation standards also deal with the matter of providing trusted attributes (e.g. X509 certificates, X509v3 attribute certificates, Kerberos tokens, SAML assertions) about users (e.g. including roles and group information) allowing for privacy and business-specific rules.

Federation also ensures that distinct identities for the same user across companies can be securely linked between two parties using federated management techniques. Federation participants can exchange identity information such that the relying party can independently validate the user's identity within their domain.

Federated single sign-on between an issuing domain and a relying domain (the federated service provider) facilitates the secure and trusted transfer of user identifiers and other attribute-related information (such as authorization roles and group memberships, and user entitlements such as EmployeeID, SSN and PIN #). Federated identity management defines the process by which the relying party is able to determine a locally valid identifier for the user, based on the (trusted) information received from the issuing party. The details of the transfer may involve multiple messages between the business and the user's enterprise of origin, which is transparent to the user.

The federation specifications provide a general model and framework; profiles describe how the model is applied in these different environments. Additional profiles may be specified for integrating the model into other environments.

Each profile specification defines how the mechanisms in WS-Federation are applied, if at all, to a given environment such as passive or active requestors.

Single Sign-on:

Single Sign-on (SSO) is a method that provides users with the ability to login one time, getting authenticated access to all their applications and resources.

The scope of the Single Sign-on standard (code-named XSSO at present) is to define services in support of:

The development of applications to provide a common, single end-user sign-on interface for an enterprise, and
The development of applications for the coordinated management of multiple user account management information bases maintained by an enterprise.

Single Sign-on can be achieved using username/password, tokens (for ex: Kerberos) or assertions (SAML etc.) An example of Single Sign-on using SAML assertions follows.

A SAML-compliant service, called a Relying Party, sends SAML Requests to an Issuing Authority, which returns SAML Assertion Responses. For example, when a user signs into a SAML-compliant service, the service sends a "request for authentication assertion" to the issuing authority, stating that the user was authenticated by a particular method at a specific time. The issuing authority returns an "authentication assertion reference" that the service can pass to other sites so they can check the user's credentials. Later, when the user visits another SAML-compliant site that requires authentication, the site uses the reference to request authentication assertion from the issuing authority, which returns an "authentication assertion," stating that the user was, in fact, authenticated by a particular method at a specific time.

Within the current specification, there are four types of assertions:

Authentication assertions
Attribute assertions
Authorization assertions
Subject assertions

When a user creates a SAML request through a service sign-on, assertions are generated by the issuing authority and transmitted within a SOAP envelope via HTTP, independent of the type of authority.

Web Services Security Specifications

The model and approach described in this paper leverage the specifications described in the white paper, Security in a Web Services World: A Proposed Architecture and Roadmap. Each of the key specifications is summarized below:

WS-Security describes how to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages.
WS-Policy represents a set of specifications that describe the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules) and how to associate policies with services and endpoints.
WS-Trust describes a framework for trust models that enables Web services to securely interoperate by requesting, issuing, and exchanging security tokens.
WS-Privacy will describe a model for how Web services and requestors state privacy preferences and organizational privacy practice statements.
WS-SecureConversation describes how to manage and authenticate message exchanges between parties, including security context exchanges and establishing and deriving session keys.
WS-Federation describes how to manage and broker the trust relationships in a heterogeneous federated environment, including support for federated identities, sharing of attributes, and management of pseudonyms.
WS-Authorization will describe how to manage authorization data and authorization policies.

Additionally, several other key Web services specifications complete the foundation layer of specifications:

WS-Addressing describes how to specify identification and addressing information for messages.
WS-MetadataExchange describes how to exchange metadata such as WS-Policy information and WSDL between services and endpoints.
WS-ReliableMessaging describes how to ensure reliable delivery of messages in the presence of unreliable networks.
WS-Transactions and WS-Coordination describe how to enable transacted operations as part of Web service message exchanges.

The combination of the specifications above and interoperability profiles will enable customers to easily build interoperable secure reliable transacted Web services that integrate within and across federations by composing federation and security specifications with other Web services specifications.

Code examples of implementations of WS-Security by some Web service tool vendors:

Sample Implementing UserToken
1. BEA Workshop Sample (Taken from BEA Workshop samples)
userToken Sample

The userToken sample shows a simple case of synchronous Web service communication, where both Web services require username and password.

Web service A sends a SOAP message to invoke Web service B's hello() method. Web service B responds by sending a SOAP message containing the hello() method's return value. Both Web services require that incoming SOAP messages be accompanied by a valued username and password and both Web services wrap outgoing SOAP messages with a username and password before they are sent over the wire.

The diagram below shows how the invoking SOAP message and the return SOAP message are processed by WSSE.

The source code for the sample is present in the zip file BEA-Workshop-sample.zip.

The WSSE policy file should have the following snippet for the incoming SOAP messages to be accompanied by a username and password:

<! -- Incoming SOAP messages must be accompanied by a username and password. -->
        <wsSecurityIn>
           <token tokenType="username"/>
    </wsSecurityIn>

The WSSE policy file should have the following snippet for the outgoing SOAP messages to be accompanied by a username and password before sending them back:

 <!--
    Accompany outgoing SOAP messages with a username and password before sending them
    out on the wire.
    -->
         <wsSecurityOut>
                <userNameToken>
                     <userName>WebLogic </userName>
                     <password type="TEXT">WebLogic </password>
                 </userNameToken>
         </wsSecurityOut>

2. Axis Sample (Taken from http://axis-wsse.sourceforge.net/)

Axis sample below implements the ‹UsernameToken› spec (Web service security UsernameToken profile)

without password
clear password
password digest
password+nonce+timestamp digest

The sample is provided in a zip file Axis-Sample.zip with the readme.txt

The request and the response of the Web service call is shown below: Request:

POST /mscomservice/mscom.asmx HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: ws.microsoft.com
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "http://www.microsoft.com/GetVersion"
Content-Length: 911
Authorization: Basic QjhmZQvNE***hidden***QjhmZQvNE

<?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
     <soapenv:Header>  
      <wsse:Security soapenv:mustUnderstand="0"
        xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">   
       <wsse:UsernameToken>    
              <wsse:Username xsi:type="xsd:string">
              B8ffemWZ1***hidden***wYJJW4bua0+</wsse:Username>    
              <wsse:Password Type="wsse:PasswordDigest"
               xsi:type="xsd:string">
               BF3utb***hidden***0lKZz4quA=</wsse:Password>    
               <wsse:Nonce xsi:type="xsd:string">
               msJPTHku44rHAqPIRvbNQA==</wsse:Nonce>    
              <wsu:Created xsi:type="xsd:string"
               xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
               2003-10-13T19:50:57Z</wsu:Created>   
            </wsse:UsernameToken>  
         </wsse:Security>
     </soapenv:Header> 
      <soapenv:Body>  
         <GetVersion xmlns=""/> 
      </soapenv:Body>
   </soapenv:Envelope>

Response:

HTTP/1.1 200 OK
Connection: close
Date: Mon, 13 Oct 2003 18:50:52 GMT
Server: Microsoft-IIS/6.0
P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI
 TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI'
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 607
<?xml version="1.0" encoding="utf-8"?>
   <soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   mlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema>
      <soap:Header>
        <wsu:Timestamp
         xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
            <wsu:Created>
                2003-10-13T18:50:52Z
            </wsu:Created>
            <wsu:Expires>
                2003-10-13T18:55:52Z
            </wsu:Expires>
         </wsu:Timestamp>
      </soap:Header>
      <soap:Body>
         <GetVersionResponse xmlns="http://www.microsoft.com">
            <GetVersionResult>
                Microsoft.Com Platform Services 1.0 Beta
            </GetVersionResult>
         </GetVersionResponse>
      </soap:Body>
   </soap:Envelope>

3. .NET Sample:

(Taken from .Net WSE Toolkit 2.0)

.Net sample below implements the <UsernameToken> spec (Web service security UsernameToken profile). The sample is provided in a zip file dotNet-Sample.zip with the readme.txt. The request and the response of the Web service call is shown below:

Request:

POST /UsernameSignCodeService/UsernameSigningService.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://stockservice.contoso.com/wse/samples/2003/06/StockQuoteRequest"
Content-Length: 4320
Expect: 100-continue
Connection: Keep-Alive
Host: localhost:8080

<?xml version="1.0" encoding="utf8" ?> 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
"xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd=
"http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/
secext">
 <soap:Header>
  <wsa:Action wsu:Id="Id7f5e1effff7943d8b7b5cc5e0c6cb435">http://stockservice.contoso.com/wse/samples/2003/06/
StockQuoteRequest</wsa:Action> 
 <wsa:From wsu:Id="Id186b3ba8942b45399204e42b1af45717">
  <wsa:Address>http://schemas.xmlsoap.org/ws/2003/03/addressing/role/anonymous</wsa:Address> 
  </wsa:From>
  <wsa:MessageID wsu:Id="Idb7637d8e2bf14460900678248140d3b3">uuid:2ec1aa36455f4dae93486f63b5805faa</
  wsa:MessageID> 
  <wsa:To wsu:Id="Id2b08b1ba0dae4af2a64310743e0e1d4e">http://localhost:8080/UsernameSignCodeService/
  UsernameSigningService.asmx</wsa:To> 
 <wsu:Timestamp>
  <wsu:Created wsu:Id="Id628e0f45fc52464ab5eefacebadc9369">20040108T02:15:13Z</wsu:Created> 
  <wsu:Expires wsu:Id="Id109cf4b1056e42c999845cd6e4873d56">20040108T02:16:13Z</wsu:Expires> 
  </wsu:Timestamp>
<wsse:Security soap:mustUnderstand="1">
 <wsse:UsernameToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
 wsu:Id="SecurityToken39d8285dc0004918836fe4e3deb1f5e2">
 <wsse:Username>rvimala</wsse:Username> 
  <wsse:Password Type="wsse:PasswordDigest">TrqsBOSUGCPZE/vabt1HfAzTfDk=</wsse:Password> 
  <wsse:Nonce>X/q8IHisS+BlqogMEvKWWg==</wsse:Nonce>
  <wsu:Created>20040108T02:15:13Z</wsu:Created> 
  </wsse:UsernameToken>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
  <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmacsha1" /> 
 <Reference URI="#Id66f3246e938a40f99340f3a43904486a">
 <Transforms>
 <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>N1leiBw5Xup+2wIX13mqLLbLgkA=</DigestValue> 
  </Reference>
 <Reference URI="#Id7f5e1effff7943d8b7b5cc5e0c6cb435">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>a7or8+SY/efprrZv4xU4n3Iysvg=</DigestValue>
  </Reference>
 <Reference URI="#Id186b3ba8942b45399204e42b1af45717">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" />
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>K/o3CIf8siH1ZiR1jFXi5gUsR30=</DigestValue> 
  </Reference>
 <Reference URI="#Idb7637d8e2bf14460900678248140d3b3">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>sDWjGDnrPtF+4nP0dC8QTez/PME=</DigestValue> 
  </Reference>
 <Reference URI="#Id2b08b1ba0dae4af2a64310743e0e1d4e">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
 <DigestValue>/eUEBSmNS1Dpz3UVcsnVktUNv7k=</DigestValue> 
  </Reference>
 <Reference URI="#Id628e0f45fc52464ab5eefacebadc9369">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" />
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>TQ+VE7VXhZE+ScjMwRri68V6Ee0=</DigestValue> 
  </Reference>
 <Reference URI="#Id109cf4b1056e42c999845cd6e4873d56">
 <Transforms>
  <Transform Algorithm="http://www.w3.org/2001/10/xmlexcc14n#" /> 
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
  <DigestValue>nNfDECaBfaPOvX5XjdxjcybSYPE=</DigestValue> 
  </Reference>
  </SignedInfo>
  <SignatureValue>LOFDssNhTjlLIacmMDRe36LImn0=</SignatureValue> 
 <KeyInfo>
 <wsse:SecurityTokenReference>
  <wsse:Reference URI="#SecurityToken39d8285dc0004918836fe4e3deb1f5e2" /> 
  </wsse:SecurityTokenReference>
  </KeyInfo>
  </Signature>
  </wsse:Security>
  </soap:Header>
 <soap:Body wsu:Id="Id66f3246e938a40f99340f3a43904486a">
 <StockQuoteRequest xmlns="http://stockservice.contoso.com/wse/samples/2003/06">
 <symbols>
  <Symbol>FABRIKAM</Symbol> 
  <Symbol>CONSTOSO</Symbol> 
  </symbols>
  </StockQuoteRequest>
  </soap:Body>
 </soap:Envelope

Response:

HTTP/1.1 100 Continue
Server: MicrosoftIIS/5.0
Date: Thu, 08 Jan 2004 02:15:14 GMT
XPoweredBy: ASP.NET

HTTP/1.1 200 OK
Server: MicrosoftIIS/5.0
Date: Thu, 08 Jan 2004 02:15:14 GMT
XPoweredBy: ASP.NET
XAspNetVersion: 1.1.4322
CacheControl: private, maxage=0
ContentType: text/xml; charset=utf8
ContentLength: 1503

<?xml version="1.0" encoding="utf8" ?> 
  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing" xmlns:wsu="http://schemas.xmlsoap.org/
  ws/2002/07/utility">
  <soap:Header>
  <wsa:From>
   <wsa:Address>http://schemas.xmlsoap.org/ws/2003/03/addressing/role/anonymous </wsa:Address> 
   </wsa:From>
   <wsa:MessageID>uuid:dc6019d8633f4d0eabf11f3963adfc15 </wsa:MessageID> 
  <wsu:Timestamp>
   <wsu:Created>20040108T02:15:14Z </wsu:Created> 
   <wsu:Expires>20040108T02:20:14Z </wsu:Expires> 
   </wsu:Timestamp>
   </soap:Header>
  <soap:Body>
 <StockQuotes xmlns="http://stockservice.contoso.com/wse/samples/2003/06">
  <StockQuote>
   <Symbol>FABRIKAM </Symbol> 
   <Last>120 </Last>
   <Date>00010101T00:00:00.000000008:00 </Date> 
   <Change>0 </Change> 
   <Open>0 </Open> 
   <High>0 </High> 
 <Low>0 </Low> 
   <Volume>0 </Volume> 
  <MarketCap>0 </MarketCap> 
   <PreviousClose>0 </PreviousClose> 
   <PreviousChange>5.5 </PreviousChange> 
   <Low52Week>0 </Low52Week> 
   <High52Week>0 </High52Week> 
   <Name>Fabrikam, Inc. </Name> 
   </StockQuote>
  <StockQuote>
   <Symbol>CONSTOSO </Symbol> 
   <Last>50.07 </Last> 
   <Date>00010101T00:00:00.000000008:00 </Date> 
   <Change>0 </Change> 
   <Open>0 </Open> 
   <High>0 </High> 
   <Low>0 </Low> 
   <Volume>0 </Volume> 
   <MarketCap>0 </MarketCap> 
   <PreviousClose>0 </PreviousClose> 
   <PreviousChange>1.15 </PreviousChange> 
   <Low52Week>0 </Low52Week> 
   <High52Week>0 </High52Week> 
   <Name>Contoso Corp. </Name>
   </StockQuote>
   </StockQuotes>
   </soap:Body>
  </soap:Envelope>

References:

Web Services Security: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
XML Encryption Syntax and Processing: http://www.w3.org/TR/xmlenc-core/
XML Signature Syntax and Processing: http://www.w3.org/TR/xmldsig-core/
Canonicalization Exclusive XML Canonicalization: http://www.w3.org/2001/10/xml-exc-c14n#
Transformations XML Decryption Transformation: http://www.w3.org/2001/04/decrypt#
Microsoft samples taken from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp
Apache Axis implementation: http://axis-wsse.sourceforge.net/
. Net implementation: http://www.microsoft.com/downloads/details.aspx?FamilyId=21FB9B9A-C5F6-4C95-87B7-FC7AB49B3EDD&displaylang=en