Web Services Security at Transport Level and Message Level

Web Services is gaining momentum in the Industry and companies have started accepting it as a new way to conduct business over the Web. Web Services currently revolves around three important protocols: SOAP, WSDL and UDDI. These protocols have reached a stage of maturity and the focus now is on security with Web Services.

There are two ways with which we can ensure security with Web Services:

• Transport level security, such as HTTP Basic/Digest and SSL, is the usual "first line of defence", as securing the transport mechanism itself makes Web services inherently secure.  The trade-off is transport dependency (Web services are more tightly coupled to the network transport layer).
• Message level security, such as WS-Security, SAML, XML Digital Signatures, and XML Encrypttion,  can be more effective and has the added flexibility that the message can be sent over any transport.

TRANSPORT LEVEL	MESSAGE LEVEL
Uses SSL Point-to-Point: Protects the "pipe" Does not work with Intermediaries Ubiquitous	Dose not use SSL Data Chunks are protected Intended to work with Intermediaries Standards still under development

Transport-level security has been around for a long time and, in fact, chances are that you've already used it when browsing the Web, since secure websites rely on transport-level security. Message-level security in Web Services is relatively new and, although it offers more features than transport-level security (e.g. a better integration with Web Services standards), its performance still leaves a bit to be desired. So, even though we would ideally like to use message-level security for everything (because of its feature-rich goodness), we will sometimes have to consider using transport-level security if performance is an issue.

Transport Level Security

Transport level security is based on Secure Sockets Layer (SSL) or Transport Layer Security (TLS) that runs beneath HTTP. SSL and TLS provide security features including authentication, data protection, and cryptographic token support for secure HTTP connections. To run with HTTPS, the service endpoint address must be in the form https://. The integrity and confidentiality of transport data, including SOAP messages and HTTP basic authentication, is confirmed when you use SSL and TLS. Web services applications can also use Federal Information Processing Standard (FIPS) approved ciphers for more secure TLS connections. [Transport level security in IBM]

Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents via the Internet. The SSL is the Industry accepted standard protocol for secured encrypted communications over TCP/IP. The SSL protocol provides transport layer security: authenticity, integrity, and confidentiality, for a secure communication across the wire.  SSL uses a cryptographic system that uses two keys to encrypt data − a public key known to everyone and a private or secret key known only to the recipient of the message. Both Netscape Navigator and Internet Explorer support SSL. Some of the security features provided by SSL are data encryption to prevent the exposure of sensitive information while data flows across the wire. Data signing prevents unauthorized modification of data while data flows across the wire. Client and server authentication ensures that you talk to the appropriate person or machine. SSL can be effective in securing an enterprise environment.  By convention, URLs that require an SSL connection start with https: instead of http:. SSL operates between communication endpoints, not between applications.

Transport Layer Security (TLS) is a security protocol from the IETF that is based on the Secure Sockets Layer (SSL) 3.0 protocol developed by Netscape. TLS uses digital certificates to authenticate the user as well as authenticate the network (in a wireless network, the user could be logging on to a rogue access point). The TLS client uses the public key from the server to encrypt a random number and send it back to the server. The random number, combined with additional random numbers previously sent to each other, is used to generate a secret session key to encrypt the subsequent message exchange.

Implementing security at the transport level means, securing the network protocol, a Web Service uses for communication. SSL provides endpoint authentication and communication privacy over the internet using cryptography. In this model, a Web Service client will use SSL to open a secure socket to a Web Service. The client then sends and receives SOAP messages over this secured socket using HTTPS. The SSL implementation takes care of ensuring privacy by encrypting all the network traffic on the socket. SSL can also authenticate the Web Service to the client using a digital certificate issued by a Certificate authority.

HTTPS provides encryption, which ensures privacy and message integrity. HTTPS also authenticates through the use of certificates, which can be used on the server side, the client side, or both. HTTPS with server-side certificates is the most common configuration on the Web today. In this configuration, clients can authenticate servers, but servers cannot authenticate clients. However, HTTPS can also be used in conjunction with basic or digest authentication, which provides a weaker form of authentication for clients. [HTTPS for implement Web Services Secuirty]

HTTP basic authentication uses a user name and password to authenticate a service client to a secure endpoint. A simple way to provide authentication data for the service client is to authenticate to the protected service endpoint to the HTTP basic authentication. The basic authentication is located in the HTTP header that carries the SOAP request. When the application server receives the HTTP request, the user name and password are retrieved and verified using the authentication mechanism specific to the server. Although the basic authentication data is base64-encoded, sending data over HTTPS is recommended. The integrity and confidentiality of the data can be protected by the Secure Sockets Layer (SSL) protocol.

Message Level Security

Message level security is an application layer service and facilitates the protection of message data between applications. Message level security is typically most useful for:

• Solutions that are designed to use predominantly asynchronous queues.
• Solutions for which application level security is important; that is solutions whose normal message paths include flows over multiple nodes perhaps connected with different protocols. Message-level security manages trust at the application level, which means security in other layers becomes unnecessary.

SOAP based communications introduces the notion of Message Level Security. In  message level security, security information is contained within the SOAP message, which allows security information to travel along with the message. For example, a portion of the message may be signed by a sender and encrypted for a particular receiver. When the message is sent from the initial sender, it may pass through intermediate nodes before reaching its intended receiver. In this scenario, the encrypted portions continue to be opaque to any intermediate nodes and can only be decrypted by the intended receiver. For this reason, message-level security is also sometimes referred to as end-to-end security.

There are some standards available for securing Web Services at XML level. They are:

• XML Encryption
• XML Digital signature API
• XKMS (XML Key Management Specification)
• SAML (Security Assertion Markup Language)

We had described more detail in our XML security section.

SSL Limitations

SSL is widely used as the security schema in web applications. However, despite its popularity, it  has some limitations. [Secure Web Services]

• SSL is designed to provide point-to-point security, which falls short for Web services because we need end-to-end security, where multiple intermediary nodes could exist between the two endpoints. In a typical Web services environment where XML-based business documents rout through multiple intermediary nodes, it proves difficult for those intermediary nodes to participate in security operations in an integrated fashion.

• SSL secures communication at transport level rather than at message level. As a result, messages are protected only while in transit on the wire. For example, sensitive data on your hard disk drive is not generally protected unless you apply a proprietary encryption technology.

• HTTPS in its current form does not support nonrepudiation well. Nonrepudiation is critical for business Web services and, for that matter, any business transaction. What is nonrepudiation? Nonrepudiation means that a communicating partner can prove that the other party has performed a particular transaction. For example, if E-Trade received a stock transaction order from one of its clients and performed the transaction on behalf of that client, E-Trade wants to ensure it can prove it completed that transaction to an arbitration committee, for example, if a dispute arises. We need some level of nonrepudiation for Web services-based transactions.

• SSL does not provide element-wise signing and encryption. For example, if you have a large purchase order XML document, yet you want to only sign or encrypt a credit card element, signing or encrypting only that element with SSL proves rather difficult. Again, that is due to the fact that SSL is a transport-level security scheme as opposed to a message-level scheme.