Web Services and its Security Challenges
The emergence of Web services represents the next evolution of e-business. Web services are Internet-based, modular applications that perform a specific business task and conform to a particular technical format. A Web service can be anything—a restaurant review article, a realtime travel advisory, an entire airline ticket reservation process. Each of these self-contained business services is an application that will easily integrate with other services (from the same or different companies) to create a complete business process. This interoperability allows businesses to dynamically publish, discover and aggregate a range of Web services through the Internet to more easily create innovative products, business processes and value chains.
Web services are Internet-based applications that fulfill a specific task or set of tasks, which can be combined with other Web services to maintain workflow or perform business transactions. Because Web services are modular, businesses can customize them to create innovative processes and value chains delivering superior customer utility and ultimately increasing shareholder value. Users can access Web services online and offline through any touch point including PCs, cell phones and personal digital assistants. Web services communicate with each other, sharing information about their functions and roles in an application workflow, the inputs they require and the outputs they generate. The result is just-in-time integration of business applications.
The Internet provides a universal platform for deploying and delivering applications
on a global scale. Extensible Markup Language (XML) provides us with a universal data
exchange standard that allows access to data irrespective of its format or location.
Web Services Description Language (WSDL) specification, co-authored by IBM and
Microsoft, and submitted to the UDDI steering committee, specifies a rich XML-based
description language for extending applications and publishing them as Web services
to be used by service brokers and search engines on the Internet. Using WSDL, businesses
can expose specific application programming interfaces (APIs) of their software
applications as services available on the Internet. These APIs can be used by other
services to incorporate the functionality into their overall mission.
simple object access protocol (SOAP), co-developed by IBM and Microsoft, and
currently under the consideration by the World Wide Web Consortium, allows businesses
to invoke and utilize Web services published using WSDL and discovered through the
UDDI registry. Using SOAP to invoke applications across the Internet and transcending
corporate firewalls allows enterprises to integrate their business processes with those of
their trading partners and suppliers.
UDDI founders IBM, Ariba and Microsoft are also implementing a public global registry for
Web services. Registration is available to any company that wants to register its business
or search for products and services offered by other companies. As Web services
become prevalent, the universal registry will help businesses locate each other and the
services they need, in a way similar to the role fulfilled by search engines on the Web.
A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be
discovered by other software systems
The use of Web services on the World Wide Web is expanding rapidly as the need for
application-to-application communication and interoperability grows. These services
provide a standard means of communication among different software applications
involved in presenting dynamic context-driven information to the user.
Essentially Web services represent next generation of distributed computing. Services are platform independent and expressed as self describing interfaces.
"Web
service" to describe application components whose functionality and interfaces
are exposed to potential users through the application of existing and emerging
Web technology standards including XML, SOAP, WSDL, and HTTP.
Security challenges.
Since Web services uses the insecure internet for mission critical transactions and with the possibility of dynamic short term relationships, security is a major concern.. Most of the application internals are exposed to the outside world. As the application is closer to the data it opens room for security threats.
Traditionally SSL, TLS, VPNs and IPSEC are some of the common ways of securing content. However these are point-to-point technologies. They create a tunnel through which data can pass. With SMIME(secure multi-purpose Internat mail exchange) protocol, data could be sent digitally signed and encrypted over the internet. However Web Services require more granularity. They have to maintain secure content and control according to their security policies. Following is a set of challenges:
Inter-enterprise Web services are dealing with untrusted clients
End-to-end isn’t just point-to-point. The creator of the message wrote the payload but intermediaries may touch or rewrite the message afterwards.
Clients and services do not have a way to negotiate their mutual constraints and capabilities before interacting.
A key benefit of the emerging Web services architecture is the ability to deliver
integrated, interoperable solutions. Ensuring the integrity, confidentiality and
security of Web services through the application of a comprehensive security mo del
is critical, both for organizations and their customers.
SSL is Not Adequate for Securing Web Services
Web services are loosely-coupled computing services that can be discovered and accessed. Multiple web services can be combined into a composite application that the individual developers of the services never envisioned.
To see why SSL is not adequate, consider a web service that can be provided indirectly to a user as shown in Figure 1. A user accesses a web site, and that web site has a system that invokes remote web services. Many web services might be deployed that way. In this scenario we have two security contexts:
- Between the user and web site, and
- Between the user and web service
Figure 1: Indirect access to a web service
The second security context, which is referred to as persistent security, requires the security of the SOAP request/reply message (between the web site and the web service) to be assured over more than one client-server connection. In other words, there is a need for persistent message security for SOAP documents. SSL is inadequate for this type of security. While SSL encrypts the data stream, it doesn't support end-to-end confidentiality; it leaves the data exposed between the web site and the web service provider.
SSL has several limitations when it comes to web services. The limitations can be summarized as follows:
SSL provides point-to-point security or operates between end-points (and not applications), but for web services we need end-to-end security in which multiple intermediate nodes could exist between the two end-points. In a web services environment, there could be multiple XML-based business documents going through multiple intermediary nodes and it will be difficult for such nodes to participate in security operations in an integrated fashion.
SSL operates at the transport level and not at the message level. In other words, messages are protected only while in transit. That is, you cannot save the message for later to prove that it hasn't been modified.
SSL doesn't support nonrepudiation. Using SSL, a communicating partner cannot prove that the other party has performed a particular transaction. That is, SSl doesn't support an end-to-end audit trail from service request to service response.
SSL doesn't support element-wise signing and encryption. Given a large XML order document, you may want to only sign or encrypt the credit card info...and that is difficult in SSL. This is because SSL is a transport-level security scheme as opposed to a message-level scheme.
Web Services Security Model Principles
Web services can be accessed by sending SOAP messages to service endpoints
identified by URIs, requesting specific actions, and receiving SOAP message
responses (including fault indications). Within this context, the broad goal of
securing Web services breaks into the subsidiary goals of providing facilities for
securing the integrity and confidentiality of the messages and for ensuring that the
service acts only on requests in messages that express the claims required by
policies.
Today the Secure Socket Layer (SSL) along with the de facto Transport Layer
Security (TLS) is used to provide transport level security for web services
applications. SSL/TLS offers several security features including authentication, data
integrity and data confidentiality. SSL/TLS enables point-to-point secure sessions.
IPSec is another network layer standard for transport security that may become
important for Web services. Like SSL/TLS, IPSec also provides secure sessions with
host authentication, data integrity and data confidentiality.
Today's Web service application topologies include a broad combination of mobile
devices, gateways, proxies, load balancers, demilitarized zones (DMZs), outsourced
data centers, and globally distributed, dynamically configured systems. All of these
systems rely on the ability for message processing intermediaries to forward
messages. Specifically, the SOAP message model operates on logical endpoints that
abstract the physical network and application infrastructure and therefore frequently
incorporates a multi-hop topology with intermediate actors.
When data is received and forwarded on by an intermediary beyond the transport
layer both the integrity of data and any security information that flows with it maybe
lost. This forces any upstream message processors to rely on the security
evaluations made by previous intermediaries and to completely trust their handling
of the content of messages. What is needed in a comprehensive Web service
security architecture is a mechanism that provides end-to-end security. Successful
Web service security solutions will be able to leverage both transport and application
layer security mechanisms to provide a comprehensive suite of security capabilities.
Point-to-point configuration
End-to-end configuration
3 Relating Web Services Security to Today's Security
Models
This Web services security model is compatible with the existing security models for
authentication, data integrity and data confidentiality in common use today. As a
consequence, it is possible to integrate Web services-based solutions with other
existing security models:
Transport Security – Existing technologies such as secure sockets (SSL/TLS) can
provide simple point-to-point integrity and confidentiality for a message. The
Web Services security model supports using these existing secure transport
mechanisms in conjunction with WS-Security (and other specifications) to provide
end-to-end integrity and confidentially in particular across multiple transports,
intermediaries, and transmission protocols.
PKI – At a high level, the PKI model involves certificate authorities issuing
certificates with public asymmetric keys and authorities which assert properties
other than key ownership (for example, attribute authorities). Owners of such
certificates may use the associated keys to express a variety of claims, including
identity. The Web services security model supports security token services
issuing security tokens using public asymmetric keys. PKI is used here in the
broadest sense and does not assume any particular hierarchy or model.
Kerberos – The Kerberos model relies on communication with the Key
Distribution Center (KDC) to broker trust between parties by issuing symmetric
keys encrypted for both parties and "introducing" them to one another. The Web
services model, again, builds upon the core model with security token services
brokering trust by issuing security tokens with encrypted symmetric keys and
encrypted testaments.
Note that while the models are compatible, to ensure interoperability, adaptors
and/or common algorithms for signatures and encryption will need to be agreed
upon or developed.
Often the existing trust models are based on business agreements. An example of
this is the UDDI Web service. In UDDI, there are several participants who provide a
Universal Business Registry through an agreement to support a set of APIs. Rather
than defining a single model for "trust" through the requirement of a specific
authentication mechanism, the "trust model" in UDDI gives the responsibility for
authentication to the node, which is the custodian of the information. That is, each
implementation of the UDDI Web service has its own authentication mechanism and
enforces its own access control policy. The "trust" is between operators, and
between the requester and the operator that is the custodian of its information.
Direct Trust using Username/Password and Transport-Level Security
The requester opens a connection to the Web service using a secure transport (e.g.
SSL/TLS). It sends its request and includes a security token that contains its
username and password. The service authenticates the information, processes the
request, and returns the result.
In this scenario, the message confidentiality and integrity are handled using existing
transport security mechanisms.
Direct Trust using Security Tokens
Here direct trust means that the requester's security token (or its signing
authority) is known and trusted by the Web service. This scenario assumes that the
two parties have used some mechanism to establish a trust relationship for use of
the security token. This trust may be established manually, by configuring the
application, or by using a secure transport to exchange keys.
The requester sends a message to a service and includes a signed security token and
provides proof-of-possession of the security token using, for example, a signature.
The service verifies the proof and evaluates the security token. The signature on the
security token is valid and is directly trusted by the service. The service processes
the request and returns a result
Security Token Acquisition
The requester issues a request to the service and includes a reference to the security
token and provides proof-of-possession. The Web service uses the provided
information to obtain the security token from the token store service and validate the
proof
As Web services are applied more broadly, as application topologies continue to
evolve to support intermediaries such as firewalls, load balancers, and messaging
hubs, and as awareness of the threats organizations face becomes more well
understood, the need for additional security specifications for Web services grows
clear.
SOAP messages are sent from an initial SOAP sender to an ultimate SOAP receiver along a SOAP message path consisting of zero or more SOAP intermediaries that process and potential transform the SOAP message. A challenge is to preserve security properties of the SOAP message from the initial SOAP sender to the ultimate SOAP receiver. Transport layer security mechanisms such as HTTP Over TLS may be used to secure messages between two adjacent SOAP nodes whereas message layer security mechanisms defined in the Web Services Security standard must be used in the presence of intermediaries or when data origin authentication is required.
Security headers may contain Security Tokens, Security Token References, Timestamps, Nonces, Signatures, Encrypted Keys and Encrypted Data. Each security header is targeted to a specific SOAP actor. A SOAP message may contain multiple security headers, however each must be targeted to a different SOAP actor. Each security header may contain multiple Security Tokens, Security Token References, Nonces, Signatures, Encrypted Keys and Encrypted Data; however there may be at most one Timestamp.
SOAP messages are composed of xml elements. Elements may be signed and/or encrypted by being referenced from a Signature or a Reference List within an Encrypted Key. Individual elements within a message may be referenced from multiple Signatures and/or Reference Lists and messages may be composed of signed and/or encrypted elements from other messages. As intermediaries process messages, they potentially sign and encrypt new and pre-existing data, as well as consume signed and encrypted data targeted at a SOAP actor that they portray. It is important to preserve the security context of the message as it undergoes these transformations.
The Security Scenarios document discusses the challenges of data integrity, data confidentiality, peer authentication and data origin authentication in the context of both transport and message level security and describes how the mechanisms available can be used alone or in combination to secure messages. It is important for architects and developers to understand that combining security mechanisms may not result in a more secure solution but may introduce vulnerabilities that were not present previously.