Microsoft Cloud Authors: Pat Romanski, Liz McMillan, Lori MacVittie, Elizabeth White, Yeshim Deniz

Related Topics: Microsoft Cloud, Containers Expo Blog

Microsoft Cloud: Article

WS-Security and WSE

WS-Security and WSE

Developers wanting to expose applications beyond proprietary runtime environments like the CLR should utilize XML Web services. XML Web services facilitate application-to-application interoperability across heterogeneous environments. Coupled with numerous standards and specifications, XML Web services form the basis of a highly distributed computing model. At the heart of this model lies the Simple Object Access Protocol (SOAP). SOAP defines a simple and extensible XML-based messaging framework that can be targeted by a variety of different programming models and over variety of different transport protocols.

The fact that SOAP messages are represented in XML raises a number of concerns when transmitting sensitive data across the wire. While existing transport protocols like SSL/TLS can address some of these concerns, they do not provide a solution that will work beyond a point-to-point scenario. It is important to remember that SOAP messages can be routed through one or more intermediaries and over one or more different transports. Given the nature of SOAP, an end-to-end solution that can be expressed at the message level and that is independent of the underlying transport protocol is needed. Enter WS-Security.

The fact that SOAP messages are represented in XML raises a number of concerns when transmitting sensitive data across the wire. While existing transport protocols like SSL/TLS can address some of these concerns, they do not provide a solution that will work beyond a point-to-point scenario. That stated, it is important to remember that SOAP messages can be routed through one or more intermediaries and over one or more different transports. Given the nature of SOAP, an end-to-end solution that can be expressed at the message level and is independent of the underlying transport protocol is needed. Enter WS-Security.

The WS-Security specification defines a set of SOAP extensions that collectively help to answer the following questions:

  • How does a SOAP message express the identity of its sender?
  • How can endpoints verify that a SOAP message has not been tampered with by an intermediary?
  • What protects the contents of a SOAP message from being read by an intermediary?

    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:

  • wsu:UsernameToken: An optional element that represents a username token
  • wsu:Id: An optional attribute denotes a URI that may be used to identity the token
  • wsu:Username: A required element that represents the user name
  • wsse:Password: An optional element that represents the password
  • wsse:Password/@Type: An enumeration describing the password type
  • wsse:Nonce: A value that varies with time, intended to minimize exposure to the reply attacks
  • wsu:Created: An optional element that represents a timestamp of the token's creation

    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="...">

    The elements used are:

  • wsu:Timestamp: An element used to define the creation and expiration times of a message
  • wsu:Created: The date and time (expressed in UTC) when the message was created
  • wsu:Expires: The date and time (expressed in UTC) when the message expires

    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:


    The elements used are:

  • wsse:BinarySecurityToken: An element that represents a binary token
  • wsse:BinarySecurityToken/@ValueType: A QName that describes the type of binary token encoded (e.g., X.509 certificate)
  • wsse:BinarySecurityToken/@EncodingType: A QName that describes the encoding used for the binary token (e.g., Base64)

    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:

    public class MyService
    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.

    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.

  • Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
    DXWorldEXPO LLC announced today that Ed Featherston has been named the "Tech Chair" of "FinTechEXPO - New York Blockchain Event" of CloudEXPO's 10-Year Anniversary Event which will take place on November 12-13, 2018 in New York City. CloudEXPO | DXWorldEXPO New York will present keynotes, general sessions, and more than 20 blockchain sessions by leading FinTech experts.
    Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how to bring data stored in a cloud database to the edge of the network (and back again) whenever an Internet connection is available. In his session at 17th Cloud Expo, Ben Perlmutter, a Sales Engineer with IBM Cloudant, demonstrated techniques for replicating cloud databases with devices in order to build offline-first mobile or Internet of Things (IoT) apps that can provide a better, faster user e...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of ...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Rodrigo Coutinho is part of OutSystems' founders' team and currently the Head of Product Design. He provides a cross-functional role where he supports Product Management in defining the positioning and direction of the Agile Platform, while at the same time promoting model-based development and new techniques to deliver applications in the cloud.
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and Bi...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...