Welcome!

Microsoft Cloud Authors: Nick Basinger, Kevin Benedict, Pat Romanski, Liz McMillan, Lori MacVittie

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.

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="...">
    <wsu:Created>...</wsu:Created>
    <wsu:Expires>...</wsu:Expires>
    </wsu>

    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:

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

    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:

    [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.

  • 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
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    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...
    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...
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    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 San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...