EBSOA Best Practices

Web Services Security

This document was prepared by Integrated Software Specialists, Inc. (“ISS”) and is to be considered confidential and proprietary to ISS and Iowa Department of Administrative Services.

ISS Best practice guide

WEB SERVICES SECURITY

7/12/06

Version 0.8

Copyright 2006 by Integrated Software Specialists (“ISS”), Inc. and the State of Iowa Department of Administrative Services (“DAS”). The copyright to these materials and any accompanying software is owned, without reservation, by ISS and The State of Iowa DAS. These materials may not be copied in whole or part without the express written permission of ISS and The State of Iowa DAS.

iOpen™, iOpen ABie™, iOpen ABef™, iOpen ABes™, iOpen ABin™, iInspect™, iDetect™, and SureStart™ are some of the trademarks owned by ISS. Other trademarks and trade names in this documentation are owned by other companies and are used for product and company identification and information only. All rights reserved. ISS is the owner of other registered and unregistered trademarks. The above list is not exhaustive.

Contact Us

Integrated Software Specialists, Inc.

1901 N. Roselle Road

Suite 450

Schaumburg, IL. 60195

1-888-477-0001

If you have suggestions for this publication, send an e-mail message to: . Your message is answered by our ISS Documentation Group.

Visit our home page at for more information about ISS products and services.

Table of Contents

1INTRODUCTION

1.1Purpose

1.2Scope

2Security Challenges

2.1Current it landscape

2.2security risks

3Best Practices

3.1define overall security strategy

3.2provide Training to soa team

3.2.1Security Training

3.2.2Testing Training

3.3Choose between message layer security and transport layer security

3.3.1Transport Layer Security

3.3.2Message Layer Security

3.4determine authentication approach

3.4.1Direct Authentication

3.4.2Brokered Authentication

3.5establish message protection strategy

3.5.1Data Origin Authentication

3.5.2Data Integrity

3.5.3Data Confidentiality

3.6develop security coding practices

3.6.1Message Validation

3.6.2Message Replay Detection

3.6.3Exception Shielding

3.7utilize web services gateways for external access

3.8improve testing process

3.8.1Static Analysis

3.8.2Dynamic Software Analysis

3.8.3Runtime Analysis

3.8.4Create and maintain reusable, regression tests scripts

3.8.5Putting it all together

3.9utilize web services security specifications

3.9.1WS-Security

3.9.2WS-Policy

3.9.3WS-Trust

3.9.4WS-Privacy

3.9.5WS-SecureConversation

3.9.6WS-Federation

3.10promote increase security interoperability

3.11implement secure auditing

3.12deploy mature web services security infrastructure

3.13governance – security policy

3.14use xml appliances, if needed

1INTRODUCTION

1.1Purpose

This best practice guide provides you with high-level overview information about Web Services Security. This paper is intended for architects and software engineers that are responsible for examining the security aspects of the Web Services currently being designed and/or developed . Information is presented in these sections:

  • Security challenges that the state government currently faces
  • Typical security countermeasures used to mitigate most common security threats.

This document assumes that the reader has a basic background in security technologies such as SSL/TLS, message level technologies of SOAP, XML encryption and digital signatures, and Web Services Security.

1.2Scope

Service-orientation represents the next major trend in enterprise computing. Utilizing this technology requires new perspectives, techniques, and tools for implementing technology solutions that meet the needs of business. The best practices described in this document only touch upon Web Services Security.

Other SOA-subject matters such as Data Standards, Service Modeling, Service-Oriented Integration, Web Services Network Infrastructure or Platform Infrastructure are addressed in other EBSOA best practice document.

.

2Security Challenges

Service-Oriented Architecture offers a number of potential benefits: provides new opportunities to connect enterprises with customers, partners, and suppliers; improves efficiency through greater reuse of services across the enterprise; and offers greater flexibility by breaking down IT silos.

These benefits make security more critical for architects, security and operations professionals, and software engineers because services are highly distributed, multi-owner, deployed to heterogeneous platforms, and often accessible across departments and organizations.

2.1Current it landscape

Security is a pressing issue in SOA because the SOA stresses machine-to-machine interactions, while most IT security is based on human-to-machine interaction.

The security infrastructure in the traditional distributed computing environment resembles islands of security. Each component or network acts as an island, with its own perimeter security, and only users within the network are considered to be trusted. Due to the distributed nature of the current enterprise systems, organizations have difficulty in administering security policies and bridging diverse security models, which leads to increased opportunities for errors and leaves holes within the security system, hence the chance of accidental disclosure and the vulnerability for attack increases.

2.2security risks

Applications exposed as Web Services provide increased flexibility but face a variety of security risks:

  • Authentication/authorization: Without the appropriate mechanisms in place, it is virtually impossible to block unauthorized use of Web Services.
  • Tampering: The message information is altered by inserting, removing or otherwise modifying information created by the originator of the information and mistaken by the receiver as being the originator’s intention.
  • Repudiation: Users (legitimate or otherwise) may deny that they made specific transactions.
  • Spoofing: A message is sent which appears to be from another principal.
  • Confidentiality: The unwarranted exposure of private data when on the wire.
  • Denial of service: Making applications unavailable by sending a huge number of requests or very large XML payloads.
  • Invalid messages: Certain XML messages can contain malicious code such as SQL statements, viruses, or worms that can compromise or corrupt data, applications, and systems, and potentially leave them exposed. This code can appear in the body of the XML document or in CDATA tags. Hackers tamper with the SOAP messages themselves to disable the service through illegitimate or malformed requests.
  • Replay attacks: A message is sent which includes portions of another message in an effort to gain access to otherwise unauthorized information or to cause the receiver to take some action (e.g. a security token from another message is added).
  • XML routing detours/external referencing: XML documents can contain references to external structures.

3Best Practices

Ensuring the integrity, confidentiality and security of services applying a comprehensive security model is critical, both for organizations and their stakeholders. Moreover, when deployed externally for consumption by other organizations or citizens, only secure Web Services can provide a justifiable integration solution, because the benefits they expose should far outweigh the risks. Fortunately, there are methods to protect against potential vulnerabilities. These issues require taking a holistic approach utilizing infrastructures, tools, and software engineering processes. This mindset takes security into consideration during the entire Web Service lifecycle, not just at deployment time.

3.1define overall security strategy

SOA security is a massive subject matter. It is easy to become paralyzed by security. Data loss, electronic snooping, hacker attacks, unauthorized access, stolen password, denial of service, are just a few of the security issues confronted by business.

Because of the advent to access and transmit data via the internet, agencies are now forced to re-examine their security infrastructure. In some cases systems are open to customers, business partners, and suppliers. But, an incomplete and outdated security solution places their information resources at risk; to avert this, their network environment must be secure.

To avoid becoming overwhelmed by security issues, the best approach is to assign a team of security experts that:

  • Define security solution(s) specific to your business needs
  • Deliver expert security analysis of the enterprise and network
  • Develop adaptable security architecture
  • Identify potential risks and vulnerabilities within your company's policies, process, networks, and systems

3.2provide Training to soa team

3.2.1Security Training

As hackers turn their attention to the software that makes up an organization's IT infrastructure, IT professionals are realizing that the best way to protect their infrastructure is building secure software at the onset. While Web Services lifecycle mirrors traditional application lifecycle in many ways, most software engineers are not trained to utilize Web Services Security.

Building secure software requires careful design, development, and deployment processes and a fundamental understanding of available security mechanisms and techniques. By eliminating potential security flaws early in the Software Development Lifecycle (SDLC), organizations reduce significant remediation costs and reduce the risk to their critical digital assets.

A considerable number of options are available regarding Web Service Security, however, to deliver secure Web Services, architects and software engineers must learn new technologies. They also must consider new threats associated with exposing functionality on potentially hostile networks.

Web Services Security training should assist the SOA team at all stages of the software engineering process to:

  • Help determine the right security solution(s) for the agency’s environment
  • Assist in making key design choices
  • Provide in-depth implementation patterns and details for security challenges
  • Help understand critical challenges in the deployment life cycle

3.2.2Testing Training

A common problem that organizations encounter is their attempt to use the same human and technological resources of testing for Web Services without implementing the proper training, processes, and technology changes. The aforementioned resources cannot be used for Web Services testing for the following reasons:

  • Web Services testing requires a different skill set in XML, SOAP, WSDLs, and other WS standards, let alone experience in security issues unique to Web Services.
  • Web Services testing can effectively implemented with specialized tools rather than tools that are designed for traditional testing. The features of these tools need to support Web Services standards and have the ability to design tests along these standards.
  • Web Services Security testing requires the facilitation of tools and practices that can exercise the tests for exposing vulnerabilities that are general to Web applications and specific to Web Services alike.

3.3Choose between message layer security and transport layer security

An architectural decision to make is whether to implement the security on the transport layer or on the message layer. TLS (Transport Layer Security) is a mature technology so both standards and tools have already been developed. It also provides a good transition path for engineers who are somewhat familiar with transport-level security but are new to Web Services. On the other hand, TLS has inherent limitations that make it inappropriate for some situations. Fortunately, message layer security provides an alternative solution for situations where TLS' limitations are troublesome.

3.3.1Transport Layer Security

The security of the transport that is being used for the Web Service can be used to protect the Web Service. The main benefit of using TLS is that it builds on top of existing Web application experience to implement the security. Many software engineers know SSL and it is easy to enable it in common Web and application servers. SSL can enforce confidentiality, integrity, authentication, and authorization, thus protecting the Web Service from capture and replay attacks, WSDL access, and scanning.

The drawback of SSL is that it is an all-or-nothing protocol. It does not have the granularity to secure certain parts of the message, nor can it use different certificates for different message parts. Moreover, if a message needs to go through multiple points to reach its destination, each intermediate point must forward the message over a new SSL connection. In this model, the original message from the client is not cryptographically protected on each intermediary because it traverses intermediate servers and additional computationally expensive cryptographic operations are performed for every new SSL connection that is established.

3.3.2Message Layer Security

Message layer security represents an approach where all the information related to security is encapsulated in the message. Securing the message using message layer security instead of using transport layer security has several advantages that include:

  • Increased flexibility: parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them.
  • Support for auditing: Intermediaries can add their own headers to the message and sign them for the purpose of audit logging.
  • Support for multiple protocols: it is possible to send secured messages over many different protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and Transmission Control Protocol (TCP) without having to rely on the protocol for security.

However, it is fair to say that message-level security is not nearly as mature as TLS. Listed below are the message layer security technologies that address some of the same concerns as TLS (privacy, authentication, and message integrity) at the message level instead of the transport level:

  • The XML Signature provides a mechanism for digitally signing XML documents or portions of XML documents. Due to the fact that the signature does not have to be in the document that is being signed, it is possible to use XML Signature to sign non-XML documents.
  • XML Encryption provides a mechanism for encrypting portions of the XML documents.
  • WS-Security is a specification that defines a standard way of securing a single message by applying authentication tokens, XML Signature, and XML Encryption to a SOAP envelope.

3.4determine authentication approach

Authentication determines the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. The recipient of the message must be able to confirm message sender identity. Authentication is considered to be a primary security feature because mechanisms used for authentication often influence mechanisms used for enabling other security features, such as data confidentiality and data origin authentication.

As computer systems have increased in complexity, the challenge of authenticating users has also increased. As a result, two models of authentication for Web Services interactions are utilized: a) Direct Authentication; and, b) Brokered Authentication.

3.4.1Direct Authentication

When both the client and service participate in a trust relationship that allows them to exchange and validate credentials including passwords, direct authentication can be performed. The Web Service acts as an authentication service to validate credentials from the client. These credentials, which include proof-of-possession that is based on shared secrets (e.g. passwords), are verified against an identity store. The benefits of using Direct Authentication include the following:

  • It represents an uncomplicated model for authenticating clients without the need for an authentication broker.
  • If the shared secret between a requester and service is compromised, only the relationship between those two parties is compromised and not the entire model.

The disadvantages associated with Direct Authentication include the following:

  • Direct Authentication does not provide single sign on capabilities. Without single sign on, the client may be forced to authenticate prior to every Web Service call or to cache the user's credentials within the application. If the user's credentials include a password, caching the password is not recommended because it may pose a security risk.
  • The decentralized nature of Direct Authentication requires that the trust relationship be managed between each point in the communication.
  • As the number of discreet relationships between clients and services increases, each with potentially different identity stores, the challenges of managing and distributing secrets becomes more complicated.
  • If a client calls a Web Service frequently, the use of Direct Authentication can increase latency, because the Web Service typically authenticates against a remote identity store.
  • Data ownership and synchronization issues can occur if each of several services has its own identity store to authenticate the same client. This is because the client's credentials may need to be duplicated across multiple identity stores.

3.4.2Brokered Authentication

In a Brokered Authentication, a Web Service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web Service.

The benefits of using Brokered Authentication include the following:

  • The authentication broker manages trust centrally. This eliminates the need for each client and service to independently manage their own trust relationships.
  • Solutions built around Brokered Authentication with a centralized identity provider are often easier to maintain than Direct Authentication solutions. When new users who require access to any of the clients or Web Services are added to the identity store, their credentials are maintained in one central point.
  • Two parties participating in Brokered Authentication do not require prior knowledge of one another to communicate. If a client is modified to call a Web Service it has never used before, the Web Service requires no changes to its configuration or data to authenticate credentials presented by the client.
  • Trust relationships can be established between different authentication brokers. This means that an authentication broker can issue security tokens that are used across organizational boundaries and autonomous security domains.

The liabilities associated with the Brokered Authentication pattern include the following:

  • The centralized trust model that is used by Brokered Authentication can sometimes create a single point of failure. Some types of authentication brokers, such as the Kerberos Key Distribution Center (KDC), must be online and available to issue a security token to a client. If the authentication broker somehow becomes unavailable, none of the parties that rely on the authentication broker to issue security tokens can communicate with each other. This problem of a single point of failure can be mitigated by implementing redundant or back-up authentication brokers, although this increases the complexity of the solution.
  • Any compromise of an authentication broker results in the integrity of the trust that is provided by the broker also being compromised. If an attacker does successfully compromise the authentication broker, it can use the authentication broker to issue security tokens, and conduct malicious activity against parties that trust the authentication broker.

3.4.3Recommended Authentication Approach

Direct authentication is the best way to go, if you do not plan to have a big SOA implementation. If you are only going to deploy only a few Web Services or SOA components, then the direct authentication approach might suffice because it’s easier to implement and the amount of SOA services that need to be maintained and controlled do not justify the need of having a centralized component to enforce security across all the state agencies.