Welcome!

Microservices Expo Authors: Elizabeth White, Pat Romanski, Mehdi Daoudi, Liz McMillan, Flint Brenton

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
    Leading companies, from the Global Fortune 500 to the smallest companies, are adopting hybrid cloud as the path to business advantage. Hybrid cloud depends on cloud services and on-premises infrastructure working in unison. Successful implementations require new levels of data mobility, enabled by an automated and seamless flow across on-premises and cloud resources. In his general session at 21st Cloud Expo, Greg Tevis, an IBM Storage Software Technical Strategist and Customer Solution Architec...
    Today companies are looking to achieve cloud-first digital agility to reduce time-to-market, optimize utilization of resources, and rapidly deliver disruptive business solutions. However, leveraging the benefits of cloud deployments can be complicated for companies with extensive legacy computing environments. In his session at 21st Cloud Expo, Craig Sproule, founder and CEO of Metavine, will outline the challenges enterprises face in migrating legacy solutions to the cloud. He will also prese...
    DevOps at Cloud Expo – being held October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real r...
    ‘Trend’ is a pretty common business term, but its definition tends to vary by industry. In performance monitoring, trend, or trend shift, is a key metric that is used to indicate change. Change is inevitable. Today’s websites must frequently update and change to keep up with competition and attract new users, but such changes can have a negative impact on the user experience if not managed properly. The dynamic nature of the Internet makes it necessary to constantly monitor different metrics. O...
    With the rise of DevOps, containers are at the brink of becoming a pervasive technology in Enterprise IT to accelerate application delivery for the business. When it comes to adopting containers in the enterprise, security is the highest adoption barrier. Is your organization ready to address the security risks with containers for your DevOps environment? In his session at @DevOpsSummit at 21st Cloud Expo, Chris Van Tuin, Chief Technologist, NA West at Red Hat, will discuss: The top security r...
    The last two years has seen discussions about cloud computing evolve from the public / private / hybrid split to the reality that most enterprises will be creating a complex, multi-cloud strategy. Companies are wary of committing all of their resources to a single cloud, and instead are choosing to spread the risk – and the benefits – of cloud computing across multiple providers and internal infrastructures, as they follow their business needs. Will this approach be successful? How large is the ...
    Enterprises are moving to the cloud faster than most of us in security expected. CIOs are going from 0 to 100 in cloud adoption and leaving security teams in the dust. Once cloud is part of an enterprise stack, it’s unclear who has responsibility for the protection of applications, services, and data. When cloud breaches occur, whether active compromise or a publicly accessible database, the blame must fall on both service providers and users. In his session at 21st Cloud Expo, Ben Johnson, C...
    Many organizations adopt DevOps to reduce cycle times and deliver software faster; some take on DevOps to drive higher quality and better end-user experience; others look to DevOps for a clearer line-of-sight to customers to drive better business impacts. In truth, these three foundations go together. In this power panel at @DevOpsSummit 21st Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, industry experts will discuss how leading organizations build application success from all...
    Most of the time there is a lot of work involved to move to the cloud, and most of that isn't really related to AWS or Azure or Google Cloud. Before we talk about public cloud vendors and DevOps tools, there are usually several technical and non-technical challenges that are connected to it and that every company needs to solve to move to the cloud. In his session at 21st Cloud Expo, Stefano Bellasio, CEO and founder of Cloud Academy Inc., will discuss what the tools, disciplines, and cultural...
    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 ...
    As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory?
    Agile has finally jumped the technology shark, expanding outside the software world. Enterprises are now increasingly adopting Agile practices across their organizations in order to successfully navigate the disruptive waters that threaten to drown them. In our quest for establishing change as a core competency in our organizations, this business-centric notion of Agile is an essential component of Agile Digital Transformation. In the years since the publication of the Agile Manifesto, the conn...
    The nature of the technology business is forward-thinking. It focuses on the future and what’s coming next. Innovations and creativity in our world of software development strive to improve the status quo and increase customer satisfaction through speed and increased connectivity. Yet, while it's exciting to see enterprises embrace new ways of thinking and advance their processes with cutting edge technology, it rarely happens rapidly or even simultaneously across all industries.
    These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
    21st International Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy. Me...
    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 their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
    "NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    One of the biggest challenges with adopting a DevOps mentality is: new applications are easily adapted to cloud-native, microservice-based, or containerized architectures - they can be built for them - but old applications need complex refactoring. On the other hand, these new technologies can require relearning or adapting new, oftentimes more complex, methodologies and tools to be ready for production. In his general session at @DevOpsSummit at 20th Cloud Expo, Chris Brown, Solutions Marketi...
    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.
    Hypertext Transfer Protocol, or HTTP, was first introduced by Tim Berners-Lee in 1991. The initial version HTTP/0.9 was designed to facilitate data transfers between a client and server. The protocol works on a request-response model over a TCP connection, but it’s evolved over the years to include several improvements and advanced features. The latest version is HTTP/2, which has introduced major advancements that prioritize webpage performance and speed.