Welcome!

Microservices Expo Authors: Pat Romanski, John Katrick, Elizabeth White, Liz McMillan, Yeshim Deniz

Related Topics: Microservices Expo, Cloud Security

Microservices Expo: Article

The Security Challenge

The Security Challenge

This article focuses on the value of Web services security. It is important to understand what Web services are and their challenges, particularly related to security. Traditionally, companies have relied on conventional, transport-level security but this approach has its limitations. The market now offers complementary XML-based solutions designed to secure documents used in Web services requests and responses. We will explore these solutions and outline "typical case scenarios" to provide a comprehensive landscape on the current offering of Web services security solutions.

Web Services Summary
Web services are loosely coupled distributed architectures that allow companies to expose business functions over the Internet. Web services are described and accessed using industry standards:

  • Extensible Markup Language (XML): Data format
  • Simple Object Access Protocol (SOAP): Messaging format
  • Web Services Description Language (WSDL): Web service description
  • Universal Description, Discovery, and Integration (UDDI): Web service publication and discovery
Because they use standard technologies widely accepted by the industry, Web services are easy to deploy and use. They don't require expensive network architectures, and can be leveraged across applications and partners: multiple applications can take part in a Web service and a Web service can be offered to multiple partners or customers. Web services offer a less costly alternative to more proprietary business-to-business (B2B) and enterprise application integration (EAI) solutions. They don't require specific clients, and they don't mandate proprietary communication protocols.

Web Services Challenges
For all their benefits, Web services face a few challenges. The emerging proliferation of Web services makes it necessary for enterprises to manage them. Web services management involves the ability to add or delete a Web service from the environment, administer Web services versions, monitor Web services performance, define administration points, and generate logs of all activities related to the Web services hosted by the management system.

Web services are starting to be used to carry out complex business transactions. Web services transactions are asynchronous and typically long-lived. A transaction is asynchronous when a client requesting a Web service does something else before receiving a response from the Web service provider. In transactional environments, asynchronous Web services transactions need to be coordinated, or "orchestrated."

Web services management and orchestration are predicated on Web services security, currently the main impediment to full-blown deployment of service-oriented architectures. Indeed, the first task in managing a Web service is to secure its access.

Web Services Security
Web services security relies on AAA ("Triple A") insurance - authentication ("you're in"), authorization ("once you're in, this is what you're allowed to do"), accounting or audit ("this is a record of what you've done").

By and large, companies deploying Web services rely on traditional transport-level security for authentication, and application-specific security for authorization and accounting or audit.

Transport-Level Security
Secure Socket Layer (SSL) is the most widely used transport-level data-communication protocol. SSL provides authentication (the communication is established between two trusted parties), confidentiality (the data exchanged is encrypted), and message integrity (the data is checked for possible corruption). SSL supports transport-level security between two SSL-enabled parties. This means that when the data is not "transported" on the communication channel, it's not encrypted; therefore, it's not secure. This is the case when you have multiple steps in a transaction. For example, when an application invokes Web Service A for purchasing and Web Service B for shipping, you need two SSL sessions. When the documents involved in the transaction are "in transit" between the two Web services, i.e., between two SSL sessions, these documents are vulnerable to attacks. This is why transport-level security falls short, particularly in multistep Web services.

Application-Based Authorization and Audit
Most companies provide authorization directly into the back-end application, which creates a "silo" infrastructure. Each application's security needs to be managed independently, thus increasing administration overhead and complex updates. Likewise, each application includes accounting and audit information that needs to be reconciled with the overall infrastructure to preserve security and consistency. Companies need to be able to validate the content of messages requesting a Web service before these messages reach the Web service, and keep track of who (or what, in the case of an application) is trying to access the Web service.

Application-Level Security
Transport-level SSL can be complemented with XML-based, application-level security, including message structure; XML content confidentiality, integrity, and authenticity; and XML content access control.

Message Structure

  • Web Services Security (WS-Security): Define security extensions to the SOAP protocol.

    XML Content Confidentiality, Integrity, and Authenticity

  • XML Encryption: Represents the encrypted content of XML data, the information that enables a recipient to decrypt it, and a mechanism for conveying encryption key information to the recipient.
  • XML-Signature: Defines the representation of signatures on digital content and procedures for processing those signatures. XML-Signature provides detailed elements supporting data integrity, signature assurance, and nonrepudiation for Web services data.

    XML Content Access Control

  • Security Assertion Markup Language (SAML): Describes authentication, attributes, and authorization decision objects (assertions) that can be exchanged between trusted partners.
  • Extensible Access Control Markup Language (XACML): Specifies policies to access XML documents based on objects (elements to be accessed in the XML document), subject (the user or service), action (read, write, create, delete). XACML relies on SAML for authentication.
  • Extensible Rights Markup Language (XrML): Describes authoring rights information to be bound to an XML document.

    Figure 1 shows the various layers involved in securing Web services. As I mentioned earlier, SSL is designed to encrypt a complete XML document and send it securely to a Web service provider. However, in many cases there is a need to secure only parts of a document, whether it is being sent to another party or stored before being further processed. In this case, we use XML Encryption and XML Signature.

     

    In order to send requests to, and receive responses from, a Web service, we use the SOAP messaging framework. SOAP is augmented with a security layer defined in the WS-Security specification. WS-Security provides an envelope for the security tokens used in Web services requests and responses, such as digital certificates, Kerberos tickets, XrML, or SAML objects.

    XML Encryption
    XML Encryption, XML-Signature, SAML, and WS-Security all work together to ensure complete Web services security.

    The XML Encryption specification describes how to represent in XML a digitally encrypted Web resource. A Web resource can be an XML document or non-XML data, such as pictures or audio files. Encryption of a document can be partial. For example, we can encrypt only a credit card number as shown in Listing 1. It defines:

  • How digital content is encrypted and decrypted
  • How the encryption key information is passed to a recipient
  • How encrypted XML data and non-XML data is identified in order to facilitate the decryption process by the recipient

    The XML Encryption specification describes how to use XML Signature with XML Encryption so that trusted parties can selectively encrypt and sign portions of documents, whether those documents are already otherwise encrypted and signed or not.

    The main element in the XML Encryption schema is <EncryptedData>. Using this element, you can define which data in the XML document needs to be encrypted, as well as the encryption value. In the example in Listing 1, the value of the <CreditCardNumber> element is encrypted.

    XML-Signature
    The purpose of an XML signature is to associate a private key with referenced data. The key is used to ensure the provenance of the signed data. In other words, an XML signature guarantees the sender's authentication, thus assuring the recipient that the document is really coming from a trusted originator.

    XML signatures apply to XML and non-XML documents. In the case of an XML document, XML signatures can apply to a part or totality of the document. They can be used with encrypted and nonencrypted documents.

    Enveloped XML-signatures are embedded in the same document they apply to. Detached XML signatures apply to data that is external to the signature itself.

    The XML Signature specification defines the signature syntax and data structures, as well as the signature processing rules (signature generation and validation). An XML signature is defined within the <Signature> element, which can be an XML document in its own right in the case of a detached signature.

    Both XML-signature and XML encryption may be applied to an XML document in random order. For example, portions of a document may be encrypted by a party after the document is signed. In this case, the signature is not verifiable. The portions of the document encrypted after signing have to be decrypted before verifying the signature. The Decryption Transform for XML Signature specification enables XML signature applications to distinguish between documents encrypted before signing and documents encrypted after signing. In Listing 2, a request for a Web service is made over HTTP using a SOAP message including an XML signature.

    The Security Assertion Markup Language (SAML)
    SAML is an XML framework for sharing security information on the Internet through XML documents. It is designed to:

  • Provide a standard way to describe existing security models
  • Enable universal sharing of authentication and authorization information across enterprises
  • Enable a platform-neutral solution with support for industry-standard transport protocols and messaging formats
  • Keep security frameworks independent of vendor implementation and architecture

    The SAML framework includes:

  • Assertions: How you define authentication, attributes, and authorization decision information
  • A Protocol: How you ask and get the assertions you need
  • Bindings and Profiles: How SAML documents (assertions) ride "on" (bindings) and "in" (profiles) industry-standard transport and messaging frameworks

    SAML Assertions
    A SAML assertion makes statements about a subject (an individual or a service). There are three kinds of statements: authentication, attribute, and authorization decision. SAML assertions can be digitally signed (see XML- Signature above). Assertions are issued by "authorities" such as security applications or Permission Management Infrastructures (PMIs). In practice, a single authority produces and issues all three types of assertions.

    All SAML assertions include the following common information:

    • Issuer ID and issuance timestamp
    • Assertion ID
    • Subject (name and optional subject confirmation, for example a public key)
    • Conditions under which an assertion is valid
    • Advice on how an assertion was made
    SAML Authentication statements are typically designed for Single Sign-On (SSO) use cases (see Listing 3).

    SAML Attribute statements and SAML Authorization Decision statements are typcially designed for distributed transactions and authorization services:

  • A SAML attribute statement asserts that Subject S is associated with Attributes A, B, etc., with values a, b, etc.
  • A SAML authorization decision statement is issued by an authorization authority, which decides whether to grant the request by Subject S for Action A to Resource R (e.g., a Web service), given Evidence E.

    SAML Protocol
    The SAML Protocol defines interaction between a SAML requester and a SAML responder (requester and responder must have a trusted relationship: they're talking about the same subject). A request is made by a SAML-aware client; a response is returned by a security service. A SAML request may include queries for authentication, attribute, and authorization decision. All types of SAML requests are met with a common SAML response, which may contain one or several assertions.

    SAML Bindings
    SAML bindings specify how SAML request-response message exchanges are mapped to standard messaging protocols. They define a SOAP-over-HTTP binding whereby SOAP is used to query a SAML authority and receive a response.

    SAML Profiles
    SAML Profiles specify how SAML assertions are inserted in, and extracted from, a message framework or protocol. They define a Web browser profile and a WS-Security profile (part of the WS-Security specification).

    Web Services Security (WS-Security)
    WS-Security is an XML framework that provides extensions to the SOAP envelope header used to implement message-level integrity and confidentiality in Web services. WS-Security includes security tokens that are sent as part of a SOAP message. Currently, WS-Security defines profiles for four types of security tokens:

    • Kerberos tickets
    • X.509 certificates
    • SAML assertions
    • XrML documents
    WS-Security can be viewed as a security information container that can include various types of security objects. To better understand how WS-Security works, let's see how it hosts SAML information.

    The WS-Security profile of SAML is based on a single interaction between a sender and a receiver.

  • The sender (a Web service consumer) obtains one or more SAML assertions and/or assertion identifiers.
  • The sender adds the assertions and/or assertion identifiers to a SOAP message using WS-Security headers.
  • The sender sends the SOAP message to the receiver (a Web service provider).
  • The receiver processes the assertions and/or assertion identifiers present in the SOAP message.

    SAML assertions and references to assertion identifiers are contained in the <wsse:Security> element, which in turn is included in the <SOAP-ENV:Header> element (see Listing 4).

    Assertion identifier references and information about assertion retrieval services are included in the <wsse:SecurityTokenRefer ence> element. One or more <saml:Assertion IDReference> elements holding the assertion identifier references may be included within the <wsse:SecurityTokenReference> element. The URI attribute of the <wsse:Reference> element specifies the location of a SAML responder implementing the SAML SOAP binding (see Listing 5).

    WS-Security is the reference specification for forthcoming complementary specifications:

  • WS-SecureConversation: Defines how security contexts are established and specify how derived keys are computed and passed.
  • WS-SecurityPolicy: Defines the policy assertions applying to WS-Security.
  • WS-Trust: Defines methods for issuing and exchanging security tokens, and methods to establish and access trust relationships.

    Putting It All Together
    This section describes a typical scenario that leverages the various security technologies described in the previous sections (see Figure 2).

     

    1.   The Web service consumer uses a local procurement application that allows him or her to fill out a purchase order in an HTML form. When he or she submits the form, the procurement application transforms it into an XML document and inserts it in the body of a SOAP message. The procurement application also inserts the user's information in the WS-Security portion of the SOAP envelope header, either using basic authentication or a (signed) SAML assertion. Once the SOAP message is ready, the procurement application POSTs the SOAP message over HTTP or (more likely) HTTPS.

    2.   The Purchasing Web service receives the SOAP message from the Web service consumer and uses its security application to decrypt and process the security information included in the WS-Security element of the SOAP envelope header. If the process is successful, the user is authenticated. In addition, the Purchasing Web service security application can analyze the information in the body of the SOAP document to determine the total amount of the purchase order with XPath. XPath expressions are used to find the elements containing price data and add them up to obtain the total amount of the purchase order. The Purchasing Web service security application can then compare the total amount of the purchase order with the entitlements of the Web service consumer. If the total amount of the purchase order is less than the entitlement assigned to the Web service consumer, authorization to process the purchase order by the Web service is granted. When the Purchasing Web Service has finished processing the order, it sends a request for shipment to the Shipping Web service (in effect, the Purchasing Web service becomes a Web service consumer). The request is wrapped up in a SOAP message, which also includes security information in the SOAP envelope header and possible additional attachments in the SOAP envelope body, such as a legal document.

    3.   When the Shipping Web service has successfully processed the shipment order, it sends a SOAP message to the Purchasing Web service.

    4.   The Purchasing Web service in turn sends a SOAP message back to the original Web service consumer, informing the user that the purchase order has been processed successfully and is being shipped. Or, the Shipping Web service can inform the original requester directly (using a SOAP message).

    References

  • XML 1.0 Second Edition Recommendation: www.w3.org/XML/
  • SOAP specification v1.1: www.w3.org/TR/SOAP
  • Working draft of the Web services security core specification: www.oasis-open.org/committees/ wss/documents/WSS-Core-08-1212-merged.pdf
  • XML Signature Recommendation: www.w3.org/DSig/Overview.html
  • XML Encryption Recommendation: www.w3.org/Encryption/2001
  • Decryption Transform for XML Signature Recommendation: www.w3.org/TR/xmlenc-decrypt
  • Security Assertion Markup Language (SAML) specification: www.oasis-open.org/committees/security
  • Extensible Access Control Markup Language specification: www.oasis-open.org/committees/xacml
  • Extensible Rights Markup Language home page: http://xml.coverpages.org/xrml.html
  • The XML Path (or XPath) specification defines a language designed to locate XML objects (elements, etc.) in an XML document: www.w3.org/TR/xpath
  • More Stories By Marc Chanliau

    Marc Chanliau has been in the software industry for more than 20 years and is currently a director of product management at Oracle where he is responsible for Identity Management solutions and innovations. He is heavily involved in security and XML standards groups including serving as the first chair person of the OASIS Security Services Technical Committee (SSTC), which culminated in the adoption of SAML as an official OASIS standard, participating on the WS-Security Technical Committee, helping to define the Liberty Alliance 2.0 specifications, and participating in the Java Specification Request (JSR) committee.

    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
    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.
    When you focus on a journey from up-close, you look at your own technical and cultural history and how you changed it for the benefit of the customer. This was our starting point: too many integration issues, 13 SWP days and very long cycles. It was evident that in this fast-paced industry we could no longer afford this reality. We needed something that would take us beyond reducing the development lifecycles, CI and Agile methodologies. We made a fundamental difference, even changed our culture...
    In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
    You often hear the two titles of "DevOps" and "Immutable Infrastructure" used independently. In his session at DevOps Summit, John Willis, Technical Evangelist for Docker, covered the union between the two topics and why this is important. He provided an overview of Immutable Infrastructure then showed how an Immutable Continuous Delivery pipeline can be applied as a best practice for "DevOps." He ended the session with some interesting case study examples.
    Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that e...
    "DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
    In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
    Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking questions to analyze and troubleshoot your infrastructure, to provisioning storage with snapshots, recovery and replication, your wildest sci-fi dream has come true. In his session at @DevOpsSummit at 20th Cloud Expo, Dan Florea, Director of Product Management at Tintri, provided a ChatOps demo where you can talk to your storage and manage it from anywhere, through Slack and similar services with...
    Containers are rapidly finding their way into enterprise data centers, but change is difficult. How do enterprises transform their architecture with technologies like containers without losing the reliable components of their current solutions? In his session at @DevOpsSummit at 21st Cloud Expo, Tony Campbell, Director, Educational Services at CoreOS, will explore the challenges organizations are facing today as they move to containers and go over how Kubernetes applications can deploy with lega...
    Learn how to solve the problem of keeping files in sync between multiple Docker containers. In his session at 16th Cloud Expo, Aaron Brongersma, Senior Infrastructure Engineer at Modulus, discussed using rsync, GlusterFS, EBS and Bit Torrent Sync. He broke down the tools that are needed to help create a seamless user experience. In the end, can we have an environment where we can easily move Docker containers, servers, and volumes without impacting our applications? He shared his results so yo...
    Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chie...
    Don’t go chasing waterfall … development, that is. According to a recent post by Madison Moore on Medium featuring insights from several software delivery industry leaders, waterfall is – while still popular – not the best way to win in the marketplace. With methodologies like Agile, DevOps and Continuous Delivery becoming ever more prominent over the past 15 years or so, waterfall is old news. Or, is it? Moore cites a recent study by Gartner: “According to Gartner’s IT Key Metrics Data report, ...
    Kubernetes is a new and revolutionary open-sourced system for managing containers across multiple hosts in a cluster. Ansible is a simple IT automation tool for just about any requirement for reproducible environments. In his session at @DevOpsSummit at 18th Cloud Expo, Patrick Galbraith, a principal engineer at HPE, discussed how to build a fully functional Kubernetes cluster on a number of virtual machines or bare-metal hosts. Also included will be a brief demonstration of running a Galera MyS...
    In his session at Cloud Expo, Alan Winters, U.S. Head of Business Development at MobiDev, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to maximize project result...
    In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
    In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
    In his session at @DevOpsSummit at 20th Cloud Expo, Kelly Looney, director of DevOps consulting for Skytap, showed how an incremental approach to introducing containers into complex, distributed applications results in modernization with less risk and more reward. He also shared the story of how Skytap used Docker to get out of the business of managing infrastructure, and into the business of delivering innovation and business value. Attendees learned how up-front planning allows for a clean sep...
    "I will be talking about ChatOps and ChatOps as a way to solve some problems in the DevOps space," explained Himanshu Chhetri, CTO of Addteq, in this SYS-CON.tv interview at @DevOpsSummit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.