The WS-Security specification defines a framework to facilitate the implementation of message-level authentication, integrity, and confidentiality in XML Web services. Much like the SOAP specification, it supports a highly extensible framework, one that can incorporate various XML-based security standards, including XML Encryption and XML Signature.

The focal point of the WS-Security specification is the <wsse:Security> element, which provides a mechanism for persisting security-related elements in a SOAP message (see Listing 1) (All of the code for this article can be downloaded from www.sys-con.com/dotnet/sourcec.cfm).

The WS-Security schema (http://schemas.xmlsoap.org/ws/2002/12/secext) restricts neither the number nor the type of elements the <wsse:Security> element can contain, since doing so would restrict extensibility. Additionally, a SOAP message can contain more than one <wsse:Security> element, provided that each is targeted at a specific SOAP role (e.g., an intermediary).

In addition to the <wsse:Security> element, WS-Security defines two token elements, <wsse:UsernameToken> and <wsse:BinarySecurityToken>. They form an extensible framework for propagating security credentials from a message sender to a designated recipient.

The UsernameToken is responsible for persisting a username and password in a SOAP message header, as shown in Listing 2. Here's a rundown of the elements used:

In the example, the following calculation is used to determine the password digest:

Digest = Base64(SHA-1(Nonce + Created + Password))

The WS-Security specification defines the <wsu:Timestamp> header to provide a mechanism for expressing the creation and expiration times of a message:

<wsu:Timestamp wsu:Id="...">
<wsu:Created>...</wsu:Created>
<wsu:Expires>...</wsu:Expires>
</wsu>

The elements used are:

Specifying a timestamp in a SOAP message can help thwart replay attacks if used in conjunction with appropriate countermeasures.

The BinarySecurityToken defines a structure to persist non-XML security credentials in a SOAP message header:

<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
wsu:Id="...">
MIIEazCCA9Sg...
</wsse:BinarySecurityToken>

The elements used are:

Web Services Enhancements 1.0 for Microsoft .NET
Web Services Enhancements 1.0 for Microsoft .NET (WSE) is the first toolset from Microsoft that allows developers to integrate and support the WS-Security specification. It consists of a .NET class library (Microsoft.Web.Services.dll) that integrates with .NET applications or the ASP.NET Web service infrastructure to provide security capabilities to XML Web services.

The WSE processing model (see Figure 1) consists of a pipeline of filters that process inbound and outbound SOAP messages. As a SOAP message is processed through the pipeline, these filters individually apply or process elements specified in the SOAP message header.

Security-related elements persisted in the header of an inbound SOAP message, e.g., <wsse:Username Token>, are processed by the SecurityInputFilter class. When a SOAP message arrives, these elements are validated and are persisted into context, represented by the SoapContext class. The SecurityInputFilter class may also process the SOAP message body in cases when its contents are signed or encrypted. Conversely, when a SOAP message is being sent, security-related elements are obtained through context and are persisted in the header of an outbound SOAP message by the SecurityOutputFilter class. Much like its counterpart, the SecurityOutputFilter class may target the SOAP message body for the purpose of encrypting its contents or applying a digital signature.

When building a client that targets an XML Web service, developers typically use the WSDL utility (wsdl.exe) to create proxy classes derived from the SoapHttpClient- Protocol class. In order to process WS-Security headers, these proxy classes must derive from the WebServicesClientProtocol class instead. In addition to the functionality provided by the SoapHttpClientProtocol class, the WebServicesClientProtocol class provides programmatic access to the SoapContext for both SOAP requests (RequestSoapContext) and SOAP responses (ResponseSoapContext).

On the server side, WSE augments the existing ASP.NET Web service infrastructure via the WebServicesExtension class, a SOAP extension for the ASP.NET runtime. ASP.NET Web service endpoints must have this class registered in web.config in order to use the services provided by WSE (see Listing 3).

Token Propagation
WSE supports token propagation through the SecurityToken class, a base class used to implement all security tokens. Credentials are persisted in a SOAP message header through the Security class, which maps to the <wsse:Security> SOAP header. An instance of this header is obtained via the SoapContext class.

The UsernameToken class contains a set of credentials in the form of a (mandatory) username and (optional) password. Its definition provides an overloaded constructor that accepts a PasswordOption enumeration as an input parameter. This enumeration specifies how the password is sent across the wire. In the case where an option of PasswordOption.SendHashed is specified, the password is a Base64-encoded, SHA-1 hashed value.

Assume a simple ASMX-based endpoint:

[WebService]
public class MyService
{
[WebMethod]
public void DoSomething()
{
// do something
}
}

Invoking this service from a client and augmenting the outbound SOAP message with a UsernameToken is a fairly simple process (see Listing 4). Listing 5 shows the code sent to the endpoint.

Messages received with <wsse:UsernameToken> elements persisted in the SOAP message header must be authenticated. Looking at the code for MyService.asmx, the endpoint does not authenticate the UsernameToken passed in the SOAP header. This is because the UsernameToken element is processed when the message intercepted by the pipeline, prior to invocation of the DoSomething method. WSE provides a mechanism to process these elements - a class that implements the IPasswordProvider interface (see Listing 6).

By modifying the service, developers can enforce a policy ensuring that a UsernameToken is always specified for a particular service. This helps to thwart unauthorized access (see Listing 7).

The <wsse:UsernameToken> elements are authenticated by the IPasswordProvider class immediately upon arrival of the message. However, before authentication can occur, this class must be properly registered in web.config. Security-related settings are defined inside the <security> element of the microsoft.web.services section (see Listing 8, all of the code for this article cam be downloaded from www.sys-con.com/dotnet/sourcec.cfm).

Configuration plays a large role in a WSE application. In addition to specifying a password provider, the security section may be used to configure symmetric key decryption, custom binary tokens, and/or policy involving X.509 certificates.

Message Integrity
Message integrity is supported in WSE through the XML Signature standard, a W3C Recommendation that defines syntax for identifying and representing signed data in an XML document. WSE supports signing SOAP messages using a UsernameToken, an X.509 certificate, or a custom binary token (e.g., Kerberos ticket) through the Signature class. This class represents a signature as defined by the XML Signature specification; it may be used to designate which parts of the SOAP message to sign. Listing 9 uses the UsernameToken of the previous example to sign the body of the SOAP message (see Figure 2).

In the example shown in Listing 10, a digital signature - represented by the <Signature> element - has signed the contents of the body - denoted by the URI listed in the <Reference> element - using a signature that is cryptographically computed based on the contents of the SOAP message and the UsernameToken, denoted by the <KeyInfo> element. Upon arrival, WSE will determine the validity of the message by using a cryptographic decoding algorithm. If valid, control is forwarded to the method being invoked. At this point, it is strongly recommended to authorize the signed authority. This requires supplementing the previous example with additional code, shown in Listing 11.

It is good policy to reject unsigned messages containing a UsernameToken persisted in the message header.

Message Confidentiality
Because SOAP is represented as plaintext, it is sometimes necessary to cryptographically encode the contents of a message to ensure its confidentiality. WSE supports message-level confidentiality through the XML Encryption standard, a W3C Recommendation that defines syntax for identifying and representing encrypted data in an XML document.

WSE supports symmetric and asymmetric encryption through the SymmetricKey and AsymmetricKey classes, respectively. Symmetric encryption uses a shared secret known by the communicating parties (e.g., Alice and Bob) to encrypt/decrypt messages. Conversely, asymmetric encryption uses public/private key pairs. Outbound messages are encrypted using the public key of its receiver. Upon message delivery, the receiver uses its private key to decrypt the message (see Figure 3). Asymmetric encryption ensures message confidentiality because only the receiver has possession of the private key.

WSE extends the support for X.509 certificates through classes located in the namespace Microsoft.Web.Services.Security.X509. These classes provide programmatic access to X.509 certificates and the X.509 certificate store of the local computer. Certificates can be obtained via the X509CertificateStore class, which provides the ability to search by a certificate's name, key identifier, or (SHA-1) hash value. The example in Listing 12 shows how a message is encrypted with the public key of the receiver's X.509 certificate. Listing 13 shows the resulting message that is sent:

In the example in Listing 13, the contents of the body - represented by the <xenc:CipherValue> element - have been encrypted with the public key of the receiver's X.509 certificate, represented by the <wsee:KeyIdentifier> element.

Bringing it All Together: WS-Forums
Recently, Don Box of Microsoft addressed a group of developers, asking them to start focusing on Web service integration through specifications like WS-Security. I felt inspired to build WS-Forums; a set of secure endpoints that expose the ASP.NET Forums object model via SOAP. The ASP.NET Forums (www.asp.net/forums) are an immensely popular Web-based discussion system developed by the ASP.NET team at Microsoft. They provide a place where developers can receive support from their peers while developing .NET applications. Despite all their goodness, the ASP.NET Forums are entirely Web-based, making them exclusively tied to the Web browser.

Essentially, WS-Forums provides a "shim" that augments the ASP.NET Forums object model, making the forums programmatically accessible via SOAP. WS-Forums use WS-Security support in WSE to augment the SOAP message header with tokens for the purpose of authentication. Developers can obtain more information on WS-Forums (including the source code) at www.ws-forums.net.

Conclusion
Web Services Enhancements 1.0 for Microsoft .NET (WSE) is a toolkit that allows developers to build .NET Framework clients and ASP.NET Web services that support WS-Security. WS-Security is a specification that solves the problem of how to allow security mechanisms to be expressed in SOAP messages, providing an end-to-end solution that can incorporate a variety of proprietary security mechanisms while remaining independent of the underlying transport protocol. Leveraging this specification through WSE, developers can begin building applications or leverage existing ones that communicate securely via SOAP.