Welcome!

Microservices Expo Authors: Elizabeth White, Liz McMillan, Yeshim Deniz, Carmen Gonzalez, Pat Romanski

Related Topics: Microservices Expo

Microservices Expo: Article

Securing Web Services

Securing Web Services

Web Services and SOAP
The actual definition of a Web service is a matter of some debate because the world of Web services can extend from small closed networks to global discovery services implemented using UDDI (Universal Description, Discovery, and Integration). But at a practical implementation level it is useful to think of a Web service as any software service that can be defined using WSDL (Web Services Description Language) and which uses SOAP for communication between a requester and a listener. This communication uses SOAP as the enveloping protocol.

Tools such as SOAP:Lite (www.soaplite.com) written by Paul Kulchenko, or the IBM Web Services toolkit (http://alphaworks.ibm.com/tech/webservicestoolkit) allow for SOAP requests to be created simply and easily.

SOAP listeners are offered in many products, including application servers such as IBM WebSphere (SOAPConnect) and databases such as Oracle 9i. Together, SOAP listeners and SOAP requesters provide a simple means of providing services to customers.

Web services allow organizations to expose software services to customers, trading partners, and even the entire world, in a simple fashion. SOAP is the ubiquitous Web services protocol and is designed to be easy to use - which is why the S in SOAP stands for "Simple." But this simplicity comes with a downside - because if security is compromised, then the benefits of Web services are wasted.

The need for security in Web services is not only related to the monetary value of goods or services that are being exchanged through the service. More abstract items such as brand value and reputation are at stake when security is compromised. In addition, a Web service may allow an attacker to reach into a company's internal systems, and this has the potential to be dangerous, whether the Web service is commercial or not. The value of the systems and/or data that are being exposed to the Internet therefore also has to be taken into account. In short, security is a requirement for practically all Web services. This article will look at how security applies to Web services - beginning with technologies that carry over from the browser-based Internet and then moving on to new initiatives specific to Web services, such as SAML and SOAP-SEC.

New Risks
Although it may seem obvious, it's sometimes forgotten that Web services make use of the same Web technologies that have suffered many security compromises in the past. Web services don't necessarily use the Web - indeed, SOAP can be sent over SMTP (i.e., e-mail) Sun's definition of a Web service describes it as: "specific business functionality exposed by a company, usually through an Internet connection, for the purpose of providing a way for another company or software program to use the service."

In practice, however, the vast majority of Web services rely on a Web server. If improperly configured, Web servers are vulnerable to such things as buffer overflow attacks or URL "button-pushing" attacks. Buffer overflow attacks consist of a stream of text sent maliciously to a Web server in order to load executable code into memory and effectively hijack the Web server. "Button-pushing" URL attacks are an effective way of probing for vulnerabilities in Web servers by mischievously sending bogus data to Web applications.

Many best practice papers and security patches already exist for Web servers. For example, Microsoft produced a guide to securing IIS 5.0 (the Web server for .NET) at www.microsoft.com/serviceproviders/whitepapers/securing_iis_whpaper.doc. However, SOAP adds a new dimension to attacks on Web servers. In addition to buffer overflow attacks against the Web server itself, these attacks can now be directed through the Web server at the SOAP engine. For example, if a Web service expects an XML document to contain a 20-character text string as data in an XML element, what happens if a 30-character text string is sent? That's why it makes sense for an incoming document to be parsed against an XML Schema, run through a DOM or SAX parser, in order to check that it's valid. The old maxim of CGI script authors - never trust your input - is still valid for SOAP.

Past Security Measures
When Netscape introduced SSL (Secure Sockets Layer) in the Netscape 1.1 browser, back in March 1995, SSL established itself as the de facto method for encrypting data between Web browsers and Web servers. SSL creates a secure channel through which sensitive data, such as credit card details, can pass. SSL uses digital certificates to provide the transparent authentication of Web servers and, optionally, Web browsers as well. Digital certificates store the public key of a person or entity and bind this key to information about that person, and to the issuer of the certificate. A public key is used to encrypt data in such a way that only the holder of the corresponding private key can decrypt the data - using an asymmetric encryption algorithm. SSL uses the RSA asymmetrical encryption algorithm as the means to create a secure "pipe" between the browser and the Web server. After the SSL connection is established, the RC4R algorithm is the preferred algorithm for encryption and decryption of data, since it is faster than RSA.

After a number of early SSL vulnerabilities were addressed, SSL proved itself to be dependable and secure. However it still relies on careful implementation and as recently as September 2001 a vulnerability was found in the SSL implementation contained in RSA Security's BSAFE toolkit, that could allow an attacker to bypass SSL client authentication, the process of determining whether someone or something is, in fact, who or what it's declared to be. SSL provides this capability through the use of digital certificates stored "at the client" - i.e., with the Web browser.

Following the success of SSL for business-to-consumer (B2C) transactions, the same technology was applied to business-to-business (B2B) transactions. Initially this was focused on "marketplaces" - in which a person manually keyed information into a Web site for product procurement. More recently, it was realized that the real value for B2B e-commerce was for "lights-out" data traffic not involving Web browsers at all. For over 15 years, electronic business documents have been sent over EDI networks that are "fenced off" from the Internet. However, these networks tend to be expensive, so it's tempting to use the public Internet instead. XML-based Web services encompass and surpass many of the capabilities of these private EDI networks, especially in the area of interoperable document types and service discovery. However, in order for Web services to truly recreate the value of private networks on the public Internet, communications confidentiality is required, along with authorization and access control, communications integrity, and an audit trail.

Digital Signatures
SSL provides the first item and a portion of the second - so let's examine the rest...

SSL is found wanting in the area of audit trails. It's difficult to prove that an SSL session occurred, or even to prove that a piece of data has been received using SSL. This is where digital signatures come into play: digital signatures use the same underlying technology as encryption, but rather than hiding data from prying eyes, digital signatures prove that a signatory did indeed sign a piece of data (this is commonly called "non repudiation"). In addition, a digital signature protects a document from tampering. This is one key difference between a digital signature and a handwritten signature. To quote EU Directive 1999/93/EC, a digital signature is "linked to the data to which it relates in such a manner that any subsequent change of the data is detectable."

A digital signature is an encrypted digest of a document. A digest is obtained by passing a document through a hashing algorithm, which produces a short string of bytes that's almost uniquely linked to that document. This digest is then encrypted with the signer's private key. Checking a digital signature involves recomputing the digest from the document, decrypting the digest in the digital signature using the signer's public key, and making sure that the two digests match.

xml-dsig
XML Digital Signature (xml-dsig) is a joint initiative of the IEFT (Internet Engineering Task Force) and the W3C (World Wide Web Consortium). xml-dsig defines a means of rendering a digital signature in XML. It's often mistakenly assumed that XML Digital Signature is just for digitally signing XML documents, whereas in fact it is for signing "any digital content," to quote the specification at www.w3.org/Signature. xml-dsig brings the well-known benefits of XML to digital signatures, making them human-readable, easily parsed, platform independent, and generally more simple to implement than preceding standards like PKCS#7. In addition, xml-dsig defines a method for multiple documents to be referenced in one signature, and mandates that information about the encryption algorithms used is also signed.

An XML Signature may be "enveloped," in which case it's located in source XML, "enveloping," in which case it wraps around the source XML, or "external," in which case it's in a separate document from the source XML. External XML Signatures may point to any URI on the Internet.

As mentioned above, xml-dsig isn't just for signing XML. Nonetheless, when XML in particular is being signed, certain considerations apply. It's important that, if the signing decision depends on what the user sees, then "sign what you see" is implemented. A user views an HTML page to fill out a Web form, resulting in a SOAP message being produced and digitally signed, and in this case it's important that the visual information presented to the user is signed. That's because the XML rendered as HTML may depend on fonts or inline images, which make it very different from the underlying XML.

Digitally signing a SOAP message presents special requirements. Portions of the Header of a SOAP message may change when the message is routed between Web services. If these are signed, then the signature is guaranteed to break. An example of a volatile SOAP Header element is the actor element, whose data changes when a SOAP message is routed upstream to a further SOAP actor.

SOAP-SEC
There are two separate proposals that describe techniques for signing a SOAP message. The first is SOAP-SEC, submitted to the W3C on February 9, 2001, by IBM and Microsoft. SOAP-SEC defines a method of signing SOAP 1.1 messages using a new header entry called SOAP-SEC:Signature. Two existing SOAP header items are reused for SOAP-SEC: "actor" to indicate the recipient of a header element, and "mustUnderstand" to indicate whether or not an application must attempt the validation of the enclosed XML Signature.

An example of a SOAP-SEC signed message is shown as Listing 1. Here we can see that the XML Signature in the SOAP message is referencing the signed data by using the "WhatWeAreSigning" ID. In addition, we can see that a Canonicalization algorithm is used. Canonicalization is needed for XML Signature because an XML document can change slightly but remain as valid XML. Examples of changes to an XML document include DOM processing, which may remove unnecessary white space between elements, or simply the differences between line endings between UNIX and Windows systems. Any of these seemingly minor changes to a document invalidates its digital signature. Prior to being signed, an XML document must therefore first be converted to a canonical form by removing spaces between elements and any platform-specific data.

WS-Security
On October 23, 2001, Microsoft produced a draft of a specification called WS-Security. WS-Security defines XML elements called <credentials>, <integrity>, and <confidentiality> that can be used in a SOAP message for, respectively, digital certificates, digital signatures, and encrypted data. As such, WS-Security is a much more detailed specification than SOAP-SEC and encompasses more than just digital signatures. It remains to be seen if WS-Security will replace SOAP-SEC.

SAML
Security Assertion Markup Language (SAML) is an OASIS (www.oasis-open.org) initiative that aims to define a standard way to securely exchange authentication and authorization information for Web services. Organizations may require that their Web services are accessed only by authenticated users. This access to authenticated users may well become as important in the future as access to suppliers or markets.

SAML breaks down a bottleneck in access management by allowing users to authenticate to one authentication service, and carry their credentials to another service. There's no need for users to reauthenticate in order to access further services. Similarly, there's no special requirement for all users of a Web service to authenticate in the same manner (e.g., by using only username/password or using only client certificate). Until now, access management and single sign-on products were limited to single organizations and/or administrative domains. SAML extends these products across the Internet by defining XML Schemas for assertions. These assertions are sent as SOAP messages over HTTP, and refer to decisions regarding authentication, attributes, and authorization.

To put this into context, Listing 2 gives an example of each type of assertion. As the listing shows, assertion is used to indicate that the user has proven their identity (i.e., authenticated) to a given authentication authority, or security domain. In this case, a password was used to authenticate. The assertion is created by the authenticating security domain in order indicate to a second domain that the user was authenticated. In addition, information about the lifetime of the assertion is included in the "NotBefore" and "NotAfter" elements. SAML uses XML Digital Signature to ensure that this message is uniquely linked to the issuer, and so that any changes to the message can be detected.

Listing 3 shows an example of an Attribute Assertion. This assertion asserts an attribute of the user - in this case their SubscriptionStatus. Again, XML Digital Signature can be used in order to ensure that this message is uniquely linked to the issuer, and cannot be changed without detection.

Finally, Listing 4 shows an Authorization Decision Assertion. This is used to assert the result of a policy - in this case the permission to access a Web page. Here we can see the Web page referenced in the "Resource" element.

SAML 1.0 was expected to be submitted as a recommendation to OASIS on March 1, 2002. Of the items deferred from SAML 1.0, the most notable is Microsoft Passport integration. Microsoft Passport will most likely be the most widely used authentication system on Earth. Integration with Passport will be crucial to SAML's success beyond being a system for linking access management products across enterprises. The OASIS Security Services Technical Committee has already committed to further development of SAML beyond version 1.0.

XACML
XACML (XML Access Control Markup Language), also developed by OASIS, is a technology complementary to SAML that allows access control policies to be expressed in XML. When a SAML assertion is received by a Web service, the Web service sends a request to a SAML PDP (Policy Decision Point), which checks an XACML policy via a PRP (Policy Retrieval Point). The advantage of using XML for access control means that policies from various access control products can be replicated easily, using XACML as a common data format.

XML Encryption
XML Encryption is a proposal that is being developed by the W3C - see www.w3.org/ Encryption. Just as XML Signature is more than just a means to sign XML, XML encryption is more than just a means to encrypt XML. It expresses meta-information about a signed digital document, so that a processor of that document is aware of what algorithms were used to encrypt the document.

XML Encryption allows for the encryption only of what must be kept confidential, allowing a business systems to continue to use, as before, the unencrypted data. Element names can be encrypted alone, or with the data contained within them, or both. Sometimes it's preferable to encrypt just the data itself, not the XML element surrounding the data, because a schema or DTD contains information about the name of the XML element that has been encrypted. This gives an attacker a valuable clue to use in a brute-force decryption attack.

XML Encryption and XML Signature are used together when a document is both signed and encrypted. For example, a SOAP message may be signed using SOAP-SEC and also carry an encrypted attachment. In order to check the signature of the data, the signed document must first be decrypted by means of a transform.

This decryption transform is being proposed by the W3C at www.w3.org/TR/xmlenc-decrypt. The proposal notes that when a document is signed first and then encrypted, the XML Signature reveals the digest value of the signed resource. This is useful information for an attacker who implements a guessing attack on the plaintext data, especially since digest algorithms are suitably fast for guessing attacks. In addition, it's noted that a signature over encrypted data is not the same as a signature over the data prior to encryption - recall the discussion above on "Sign what you see."

XKMS
The final protocol to consider is XKMS (XML Key Management Protocol). XKMS isn't just a building block for secure Web services, it's also a means of using Web services to simplify a number of complicated PKI (public key infrastructure) protocols. As such, it is as much about applying Web services to security as applying security to Web services. XKMS incorporates X-KISS (XML Key Information Service Specification), which provides an important component of Web services security - namely a means to query the trustworthiness of a user's digital certificate. A digital certificate can be registered with an XKMS service using another subcomponent of XKMS - X-KRSS (XML Key Registration Service Specification). XKMS has been submitted to the W3C as a W3C Note - see www.w3.org/TR/xkms.

Combining Security Measures
UDDI has a number of unique security requirements, many of which may be addressed by a combination of XML Digital Signature, SAML, and XACML. The UDDI v1 specification makes no mention of security, so security for UDDI is presently a matter for debate. But one likely scenario would be:

  1. The UDDI registry and service provider must authenticate one another so that a third party cannot register services on behalf of the genuine service provider.
  2. The UDDI registry must determine if the service provider has authority to register its service. The act of publishing a service in a UDDI directory may be protected by digital signatures and, possibly, encryption, so that the service provider can't repudiate the offering of the service; and "sniffers" can't determine details of service.

Similarly, SAML and XACML allow the UDDI registry to determine if the service requester has authority to find the service registered by the service provider. Digital signatures and encryption can be used to protect the authenticity, integrity, and confidentiality of exchanged data. If the service requester is authorized to find the service, the UDDI registry signs the WSDL that's returned to the service requester. It may also encrypt the data if the service type is intended to be kept confidential. In addition, any alteration to a published WSDL interface is effectively a denial-of-service attack because the published service can no longer be discovered. Therefore, it's important that published WSDL interfaces are digitally signed. Note that the digital signature on the WSDL would often be that of the service provider, not the UDDI registry. The UDDI registry would sign the SOAP message containing the WSDL sent back to the service requester. This is an example of a signature over data which has already been signed.

Conclusion
Many of the technologies discussed in this article remain works in progress. XML Signature is closest to ratification, XML Encryption is largely defined, but security for UDDI remains a matter for debate. It seems certain that a combination of XML Signature, XML Encryption, SAML, XAC ML, and XKMS will need to be used to secure Web services. As Web services pass beyond the initial pilot and proof-of-concept stage, security is vital for them to achieve the scale of mass deployment that has been widely predicted.

More Stories By Mark O'Neill

Mark O'Neill is VP Innovation at Axway - API and Identity. Previously he was CTO and co-founder at Vordel, which was acquired by Axway. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.

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.


@MicroservicesExpo Stories
Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership abi...
The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). He discussed from business and technical viewpoints what exactly they are, why we care, how they are different and in what ways, and the strategies for IT to transi...
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm.
As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and micro services. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your contain...
As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningf...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In his Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, will explore t...
DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, explored HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 - November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
Everyone wants to use containers, but monitoring containers is hard. New ephemeral architecture introduces new challenges in how monitoring tools need to monitor and visualize containers, so your team can make sense of everything. In his session at @DevOpsSummit, David Gildeh, co-founder and CEO of Outlyer, will go through the challenges and show there is light at the end of the tunnel if you use the right tools and understand what you need to be monitoring to successfully use containers in your...
What if you could build a web application that could support true web-scale traffic without having to ever provision or manage a single server? Sounds magical, and it is! In his session at 20th Cloud Expo, Chris Munns, Senior Developer Advocate for Serverless Applications at Amazon Web Services, will show how to build a serverless website that scales automatically using services like AWS Lambda, Amazon API Gateway, and Amazon S3. We will review several frameworks that can help you build serverle...
The IT industry is undergoing a significant evolution to keep up with cloud application demand. We see this happening as a mindset shift, from traditional IT teams to more well-rounded, cloud-focused job roles. The IT industry has become so cloud-minded that Gartner predicts that by 2020, this cloud shift will impact more than $1 trillion of global IT spending. This shift, however, has left some IT professionals feeling a little anxious about what lies ahead. The good news is that cloud computin...
SYS-CON Events announced today that HTBase will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. HTBase (Gartner 2016 Cool Vendor) delivers a Composable IT infrastructure solution architected for agility and increased efficiency. It turns compute, storage, and fabric into fluid pools of resources that are easily composed and re-composed to meet each application’s needs. With HTBase, companies can quickly prov...
An overall theme of Cloud computing and the specific practices within it is fundamentally one of automation. The core value of technology is to continually automate low level procedures to free up people to work on more value add activities, ultimately leading to the utopian goal of full Autonomic Computing. For example a great way to define your plan for DevOps tool chain adoption is through this lens. In this TechTarget article they outline a simple maturity model for planning this.
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might...
The rise of containers and microservices has skyrocketed the rate at which new applications are moved into production environments today. While developers have been deploying containers to speed up the development processes for some time, there still remain challenges with running microservices efficiently. Most existing IT monitoring tools don’t actually maintain visibility into the containers that make up microservices. As those container applications move into production, some IT operations t...
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Software development is a moving target. You have to keep your eye on trends in the tech space that haven’t even happened yet just to stay current. Consider what’s happened with augmented reality (AR) in this year alone. If you said you were working on an AR app in 2015, you might have gotten a lot of blank stares or jokes about Google Glass. Then Pokémon GO happened. Like AR, the trends listed below have been building steam for some time, but they’ll be taking off in surprising new directions b...
@DevOpsSummit has been named the ‘Top DevOps Influencer' by iTrend. iTrend processes millions of conversations, tweets, interactions, news articles, press releases, blog posts - and extract meaning form them and analyzes mobile and desktop software platforms used to communicate, various metadata (such as geo location), and automation tools. In overall placement, @DevOpsSummit ranked as the number one ‘DevOps Influencer' followed by @CloudExpo at third, and @MicroservicesE at 24th.