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
    Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
    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...
    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...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    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...
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...