Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Elizabeth White, Derek Weeks, Mehdi Daoudi

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
    As many know, the first generation of Cloud Management Platform (CMP) solutions were designed for managing virtual infrastructure (IaaS) and traditional applications. But that's no longer enough to satisfy evolving and complex business requirements. In his session at 21st Cloud Expo, Scott Davis, Embotics CTO, explored how next-generation CMPs ensure organizations can manage cloud-native and microservice-based application architectures, while also facilitating agile DevOps methodology. He expla...
    SYS-CON Events announced today that Synametrics Technologies will exhibit at SYS-CON's 22nd International Cloud Expo®, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Synametrics Technologies is a privately held company based in Plainsboro, New Jersey that has been providing solutions for the developer community since 1997. Based on the success of its initial product offerings such as WinSQL, Xeams, SynaMan and Syncrify, Synametrics continues to create and hone in...
    DevOps promotes continuous improvement through a culture of collaboration. But in real terms, how do you: Integrate activities across diverse teams and services? Make objective decisions with system-wide visibility? Use feedback loops to enable learning and improvement? With technology insights and real-world examples, in his general session at @DevOpsSummit, at 21st Cloud Expo, Andi Mann, Chief Technology Advocate at Splunk, explored how leading organizations use data-driven DevOps to clos...
    "I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optimal end user experience over hybrid-cloud and multi-cloud environments, no matter what the current state of the infrastructure is. To employ a delivery automation strategy that reflects your business rules, making r...
    The past few years have brought a sea change in the way applications are architected, developed, and consumed—increasing both the complexity of testing and the business impact of software failures. How can software testing professionals keep pace with modern application delivery, given the trends that impact both architectures (cloud, microservices, and APIs) and processes (DevOps, agile, and continuous delivery)? This is where continuous testing comes in. D
    Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
    Admiral Calcote - also known as Lee Calcote (@lcalcote) or the Ginger Geek to his friends - gave a presentation entitled Characterizing and Contrasting Container Orchestrators at the 2016 All Day DevOps conference. Okay, he isn't really an admiral - nor does anyone call him that - but he used the title admiral to describe what container orchestrators do, relating it to an admiral directing a fleet of container ships. You could also say that they are like the conductor of an orchestra, directing...
    The past few years have seen a huge increase in the amount of critical IT services that companies outsource to SaaS/IaaS/PaaS providers, be it security, storage, monitoring, or operations. Of course, along with any outsourcing to a service provider comes a Service Level Agreement (SLA) to ensure that the vendor is held financially responsible for any lapses in their service which affect the customer’s end users, and ultimately, their bottom line. SLAs can be very tricky to manage for a number ...
    Our work, both with clients and with tools, has lead us to wonder how it is that organizations are handling compliance issues in the cloud. The big cloud vendors offer compliance for their infrastructure, but the shared responsibility model requires that you take certain steps to meet compliance requirements. Which lead us to start poking around a little more. We wanted to get a picture of what was available, and how it was being used. There is a lot of fluidity in this space, as in all things c...
    Gaining visibility in today’s sprawling cloud infrastructure is complex and laborious, involving drilling down into tools offered by various cloud services providers. Enterprise IT organizations need smarter and effective tools at their disposal in order to address this pertinent problem. Gaining a 360 - degree view of the cloud costs requires collection and analysis of the cost data across all cloud infrastructures used inside an enterprise.
    Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task...
    The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
    The notion of improving operational efficiency is conspicuously absent from the healthcare debate - neither Obamacare nor the newly proposed GOP plan discusses the impact that a step-function improvement in efficiency could have on access to healthcare (through more capacity), quality of healthcare services (through reduced wait times for patients) or cost (through better utilization of scarce, expensive assets).
    Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...
    The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applications. This transformation also implies an evolution to more and more intelligent applications to better engage with the customers, while creating significant market differentiators. In both cases, the cloud has become a key enabler to embrace this digital revolution. So, moving to the cloud is no longer the question; the new questions are HOW and WHEN. To make this equation even more complex, most ...
    Some journey to cloud on a mission, others, a deadline. Change management is useful when migrating to public, private or hybrid cloud environments in either case. For most, stakeholder engagement peaks during the planning and post migration phases of a project. Legacy engagements are fairly direct: projects follow a linear progression of activities (the “waterfall” approach) – change managers and application coders work from the same functional and technical requirements. Enablement and develo...
    Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
    For DevOps teams, the concepts behind service-oriented architecture (SOA) are nothing new. A style of software design initially made popular in the 1990s, SOA was an alternative to a monolithic application; essentially a collection of coarse-grained components that communicated with each other. Communication would involve either simple data passing or two or more services coordinating some activity. SOA served as a valid approach to solving many architectural problems faced by businesses, as app...