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:

1.
Between the user and web site, and
2.
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 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
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.